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VIRTUALI Z ED MULTIMEDIA CONNECTION SYSTEM 
Background of the Invention 
The invention relates generally to multimedia 
5 connection systems. 

With few exceptions f systems supporting facilities 
for the sharing of live audio and motion-video images 
have provided integrated hardware platforms that 
contained both video encoding/decoding devices and an 

10 Integrated Services Digital Network Basic Rate Interface 
(ISDN/BRI) . Stand-alone, dedicated video conferencing 
systems began as wholly proprietary designs (early video 
conferencing systems from PictureTel Corporation and 
Compression Laboratories, Inc.) / tout, by 1993 , 

is conferencing products based on the personal computer 

became available. These systems relied upon standardized 
operating systems to host command, control, and user 
interface software components. Specialized hardware 
support for videoconferencing services was implemented in 

20 adapter board configurations that contained real-time 

video processing facilities, integrated with an ISDN/BRI 
hardware component (PictureTel S1000, CLI Eclipse) . For 
all intents and purposes, the software architectures used 
in the implementation of the motion-video connectivity 

25 sub-systems have been extremely tenuous, and essentially 
unusable as discreet modular components in that they 
lacked a comprehensive, extensible software model to 
support the diversity of underlying hardware 
technologies . 

30 Perhaps the best attempt at creating a simple, 

reusable motion-video connectivity sub-system for 
integration into second-party products is available from 
Zydacron, Inc. (Zydacron Z240, Z250) • Even the simple, 
clean implementation of this system's software control 

35 mechanism requires many months of specialized software 



WO 98/09213 

PCT/US97/150I8 



- 2 - 

development, including significant design and 
implementation of complicated protocol components, before 
the sub-system is usable in a commercial product. 

ITU-T RECOMMENDATION H.320 

5 Motion-video connectivity, between systems from 

different vendors, is possible only through the general 
acceptance of standardized protocols for interconnection 
between local and remote stations. in March of 1993, the 
International Telecommunication Union (ITU-T) adopted 
10 Recommendation H.221 (LINE TRANSMISSION OF NON-TELEPHONE 
SIGNALS) as the standard for the interconnection of 
devices supporting the exchange of audio, video, and 
binary data types (see ITU-T Recommendation H.221, FRAME 
STRUCTURE FOR A 64 TO 1920 kbits/s CHANNEL IN AUDIOVISUAL 
TELES ERVICES , 1994. This protocol is grouped with two 
other related interconnection protocols under the rubric 
of Recommendation H.320, which is now the generally 
accepted set of protocols for implementing composite 
audio/motion-video/data connectivity across the 
Integrated Services Digital Network as embodied in 
narrow-band visual telephone systems ISDN- see, ITU-T 
Recommendation H.320, NARROW— BAND VISUAL TELEPHONE 
SYSTEMS AND TERMINAL EQUIPMENT, 1994). Recommendation 
H.320 is a virtualized definition of an extensible, 
finite set of capabilities, device modes, data transfer 
frame structures, and call control procedures. At some 
level in the software layers that comprise H.320- 
compliant connectivity stations, there must be (by 
definition) an implementation of a significant subset of 
the Recommendation H.320 multimedia interconnection 
services. Despite this distinct commonality shared by 
inter-connectable stations, there are no commercially 
available software models, known to this author, that 
promote these standardized audiovisual/data connectivity 
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services to a useful , consistent, reusable kernel of 
device-independent software control elements. 



SYSTEM ARCHITECTURES 

System and user interface software designs for 
5 multimedia connectivity stations have typically been 
derived directly from the service profile of the 
underlying devices that they control — multimedia 
connectivity software architectures are mostly hardware 
driven. Since multimedia connectivity tasks, such as 

10 videoconferencing, require synchronous encoding/decoding 
of audio and video data at high data rates emanating 
to/ from synchronous data transfer connectivity devices, 
most of the motion-video connectivity devices integrate 
all the necessary components onto one large, multi- 

15 purpose device. Typically these devices take the, form of 
an ISA or EISA personal computer adapter that includes 
additional hardware support for specialized video overlay 
functions. Without a major software development effort, 
it is impossible to utilize the manufacturer's sub-system 

20 for a new connectivity application. Those wishing to 

impart videoconferencing services to their enterprise are 
most frequently restricted to the single software 
application program provided by the hardware vendor; that 
is the only one capable of sufficiently driving the 

25 vendor's complicated hardware configurations. PictureTel 
Corporation, Zydacron, Inc., and Compression Labs, Inc., 
design and develop most of the world's motion-video 
connectivity sub-systems according to this multiple 
integrated device architecture. These systems perform 

30 well for stand-alone videoconferencing purposes. Recent 
attempts by Intel Corporation to produce software video 
solutions with minimal hardware support, are of inferior 
image and sound quality. The allocation of valuable 
central processing unit resources to real-time video 
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encoding/decoding tasks is inefficient at 128 kbit/s data 
transfer rates, and entirely inappropriate at transfer 
rates of 384 kbit/s, or more. a data transfer rate of 
384 kbit/s is required to produce motion-video connection 
services with frame rates and image clarity sufficient 
for large-scale acceptance of these technologies; a 128 
kbit/s data transfer rate produces video image quality 
that can best be described as "disappointing" to 
uninitiated technology customers who typically expect a 
broadcast quality television image (see D. Minoli and R. 
Keinath, Distributed Multimedia Through Broadband 
Communications Services, Norwood, Massachusetts, Artech 
House, pp. 187-207, 1994). There will likely continue to 
be a continuous stream of hardware and software solutions 
to improve the quality of motion-video connectivity using 
personal computers, and systems will continue to undergo 
rapid change as high-bandwidth ISDN connections become 
cost effective and generally available. in consideration 
of the extraordinary engineering effort required to 
produce motion-video connectivity systems, and the 
difficulties of developing software to support new 
devices, more can be done to reuse the high-level 
applications and protocol support code developed for 
these products. 

Summary r>f * he Tnypn^ np 
VIRTUALI2ED SYSTEM DE8IGN8 

An analogous problem to that of the hardware- 
driven software designs in multimedia connection systems 
can be found in the early attempts to create Graphical 
User interfaces for the wide variety of graphics hardware 
used with personal computers. Here again, hardware 
features influenced overlaying software designs, with a 
proprietary device driver interface supported by almost 
every distinct video graphics adapter manufacturer. The 
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Microsoft Windows Operating Environment, and the 
operating System/ 2 Presentation Manager, solved the 
problems related to video graphics hardware variability 
by abstracting the services of these devices to a fully 
5 device-independent model* The original Microsoft solution 
is called the Graphics Device Interface (GDI) , and it is 
the paradigm shift in video graphics technology made 
possible by this particular product component, that has 
helped promote the Graphical User Interface (GUI) to its 

10 ubiquitous market position. The invention of the GDI 
allowed the development of GUI applications that would 
run over any graphics hardware integrated according to 
the GDI's prescribed methodology (see C. Petzold, 
Programming Windows 3.1, Redmond, Washington, Microsoft 

15 Press, Chapter 11, 1992. 

The principle that underlies the GDI is that there 
exists a finite set of graphical operations that will 
enable a software developer to draw just about anything 
on a bitmapped display device. It is taken into 

20 consideration that some graphics hardware is more or less 
suitable for the direct implementation of these 
operations; some operations may not be supported at all 
by the hardware. To derive a set of abstract, logical 
operations, without giving consideration to the 

25 underlying mechanism needed to support them, is referred 
to as the process of virtualization. In a GDI 
implementation, any graphics operation that may be 
supported directly by a hardware function, is accessed 
directly using a vendor-specific device driver. If a 

30 close mapping of a physical to a logical graphical 
operation exists, some software modification of the 
physical operation, to better implement the desired 
logical operation, is invoked as needed. If no hardware 
support exists for the operation, it may be emulated 

3S entirely in software, or marked as a task of which the 
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vendor-specific driver is incapable. A structured 
capability report mechanism is available to applications 
using GDI, so that they may determine if a specific 
operation is even possible. Regardless of whether a 
particular operation is supported by the graphics device 
per se, or can be emulated, if there is any way GDI can 
fulfill the request for service, then the graphical 
system is considered to be capable. This same 
virtualization principle behind the Graphics Device 
Interface can be expanded to create a logical description 
of operations necessary to fully describe multimedia 
interconnection operations. 

A VIRTUAL! ZED MULTIMEDIA CONNECTIVITY SYSTEM 

Videoconferencing is but one interesting 

15 multimedia connectivity service. However, what is needed 
is a change in the way we view multimedia 
interconnection, not only in terms of the logical 
operations we wish to perform, but in a way that most 
advantageously applies those operations to specific 

20 configurations of audio-video transducers, and diverse 
sources of synchronous data connectivity. A generalized 
model for multimedia connectivity application development 
must take into consideration that the essence of these 
technologies is the structured sharing of sound and light 

25 spectral data (as opposed to binary data) . The vendor- 
specific facets of media transducers and network 
interfaces employed to implement related services must be 
rendered entirely irrelevant to the operation of software 
programs desirous of device-independent audiovisual 

30 teleservices. 

In that regard, an efficient, consistent, and 
extensible presentation of multimedia connectivity 
services to software programs is achieved through the 
appropriate run-time binding of media transducers to 
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connectivity protocol stacks. Device-independent 
multimedia connectivity services are abstracted, in 
software, to an externally consistent media and network 
interface control interface. A single binary software 
5 object is constructed to encapsulate all relevant 

hardware and software components necessary to support 
virtualized multimedia connection services. These 
services are accessed through manipulation of the 
object's members. A specific instance of the 

10 virtualized, encapsulated media control and connectivity 
components required to implement the defined services, is 
referred to as a Virtual Connection Object (VCO) . Each 
VCO contains a reusable Virtual Device Interface (VDI) 
software component that contains the VCO's Software 

15 Control Interface (SCI) and device- independent 

media /connection device control methods. The VDI derives 
implementation of its services from a Virtualization 
Layer (VL) . The Physical Device Interface (PDI) provides « 
control of the physical media transducers and one or more 

20 network interface units, in a fashion consistent with 

both the techniques specified by their manufacturers, and 
in a way that enables their efficient utilization by 
methods in the VL. Device-generated events, occurring in 
real-time, asynchronous with the system scheduler, are 

25 inserted—into an infinite event queue, to be periodically 
dispatched to the VDI, synchronous with the system 
scheduler. Physical limitations on the level of service 
provided by encapsulated media transducers /network 
interface, are expressed as the Local Capabilities. When 

30 connected, the capabilities of the remote station are 
expressed as the Remote Capabilities, and are available 
to the constructor of the VCO. The quality of the 
connection is described as the logical intersection of 
both the Local Capabilities and the Remote Capabilities, 

35 and is referred to as the Connection Capabilities, VCO 
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implementations abstract multimedia connectivity services 
to the level of the Open Systems Interconnection 
Reference Model Presentation Layer; device-dependent 
control methodologies for vendor-specific media 
transducers and connectivity protocol stacks have no 
representation in the Presentation Layer. Software 
programs that construct VCOs and utilize the presented 
multimedia connectivity services, are referred to as VCO 
Clients. These device-independent connectivity programs 
realize the benefits of interoperability across any 
multimedia connectivity sub-system that encapsulates its 
services into a Virtual Connection Object, according to 
the disclosed methodology. 

In general, in one aspect, the invention is a 
multimedia connectivity program residing in computer 
readable memory. The connectivity program when executed 
on a computer providing to an application program 
multimedia connectivity services through a real-time 
multimedia device control subsystem including components 
selected from among a plurality of multimedia devices and 
a plurality of real-time multimedia protocol stacks. The 
program includes a single binary object encapsulating a 
virtual device interface and a device control interface. 
The virtual device interface includes a plurality of 
virtual methods that represent logical operations 
available to the application program for controlling the 
multimedia device control subsystem. The plurality of 
virtual functions are completely independent of the 
components within the device control subsystem. The 
device control interface mapps the plurality of virtual 
functions to physical control methods which control the 
components of the multimedia control subsystem. 

In preferred embodiments, the device control 
interface includes a plurality of media control objects 
which represent audiovisual and binary data streams 
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associated with the components of the plurality of 
devices and/or real-time multimedia protocol stacks. The 
virtual device interface is configured to present a 
logical representation of the multimedia connectivity 
5 services provided by the connectivity program. The 

device control interface includes a virtualization layer 
and a physical device interface layer, the virtualization 
layer being located between the virtual device interface 
and the physical device interface. The physical device 

10 interface directly interfaces to the device control 
subsystem to provide a physical implementation of 
services requested by the application through the virtual 
device interface. The virtualization layer resides 
between the virtual device interface and the physical 

15 device interface layer and is configured to translate and 
map device control mechanisms employed by the underlying 
multimedia control sub-system to representations required 
by the virtual methods of the virtual device interface. 

Also, in preferred embodiments, the plurality of 

20 media control objects provides the multimedia 

connectivity control program with a pool of media device 
signal resources. Each of the plurality of media control 
objects is classified as at least one of type of the 
group consisting of an audio type, a video type, an image 

25 type,— ^a«cUa binary data type. Also, each of the 

plurality of media control objects represents a signal 
from the group consisting of a signal from a remote 
station, a signal to a remote station, a signal from a 
local output device, and a signal to a local output 

30 device. The operations performed on the plurality of 

media control objects by the physical device layer under 
control of the virtual device interface implements a 
logical software switching mechanism. The virtual device 
interface implements a plurality of public member 

35 functions, the virtual functions being a subset of those 
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public member functions and the plurality of public 

funftl fUnCtl ° nS "Pontine, all of the public member 

bv th ? Blnary ° bjeCt th " «• accessible 

by the application program. 

5 In general, in anotehr aspect, the invention is a 

computer programed to provide to an application program 
multimedia connectivity services through a real-time 
multimedia device control subsystem. The multimedia 
device control subsystem includescomponents selected from 
io among a plurality of multimedia devices and a plurality 
Of real-time multimedia protocol stacks. The programmed 
computer includes a virtual device interface and I device 
control interface, both of which are encapsulated in I 
single binary object. The virtual device interface 
1. includes a plurality of virtual methods that represent 
logical operations available to the application program 
for controlling the multimedia device control subsystem 
The plurality of virtual functions are completely 
independent of the components within the device control 
20 subsystem. The device control interface maps the 
Plurality of virtual functions to physical control 
methods which control the components of the multimedia 
control subsystem. 

in general, in yet another aspect, the invention 
9 COm P uter implemented method of providing multimedia 
connectivity services through a real-time multimedia 
device control subsystem. The multimedia device control 
subsystem includes components selected from among a 
Plurality of multimedia devices and a plurality of real- 
o time multimedia protocol stacks. The method includes the 
steps of defining and supporting by computer implemented 
steps a virtual device interface; and defining and 
supporting by computer implemented steps a device control 
interface. Both the virtual device interface and the 
device control interface are encapsulated in a single 
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binary object. The virtual device interface includes a 
plurality of virtual methods that represent logical 
operations available to the application program for 
controlling the multimedia device control subsystem* The 
5 plurality of virtual functions are completely independent 
of the components within the device control subsystem. 
The device control interface maps the plurality of 
virtual functions to physical control methods which 
control the components of the multimedia control 

10 subsystem. 

Multimedia connectivity sub-systems r when 
developed for use in a VMCS, present an externally 
consistent, fully abstracted set of logical operations to 
software programs, therewith exposing the faculty to 

15 create adjunct, device-independent , interoperable 

multimedia connectivity isoftware application programs. 
The disclosed invention is a methodology to enable the 
structured sharing of spectral information between 
interconnected microcomputer stations. Though 

20 principally intended to facilitate control of live audio 
and (motion) video information, this comprehensive 
connectivity paradigm incorporates mechanisms for store- 
forward operations; binary data object transfers are also 
supported. For the purposes of practical consideration, 

25 the VMCS pursues a classic client-server model of 
application/sub-system interaction. The sub-system 
presents a coherent software control mechanism to device- 
independent connectivity applications created explicitly 
to utilize its structured, highly-typed, set of services. 

30 Insofar as software programs benefit from 

virtualized binary data sharing technologies, the same 
benefits may be realized by those sharing spectral 
inf ormation, if the system is implemented as a 
Virtualized Multimedia Connection System (VMCS) . 
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Other advantages and features win become apparent 
from the following description of the preferred 
embodiment and from the claims. 

fiElef Description sf ^ Drawing 
5 Fig. i shows the symbol conventions used in the 

following figures; 

Fig. 2 is a block diagram showing a VCMS component 
overview; 

Fig. 3 is a block diagram showing a VCO 
10 architecture overview; 

Fig. 4 is a block diagram showing the VCO software 
architecture; 

Fig. 5 is a block diagram showing the VCO client 
application software architecture; 

" Fig * 6 is a bloc * diagram showing the vco class 

derivation; 

Fig. 6A is a table of the VCO exception handling 
modalities; 

Fig. 6B is a table of the VCO trace output 
20 modalities; 

Fig. 6C is a table of vco events which trigger 
notification; 9 

Fig. 7 is a block diagram showing the device 
control mechanism; 

25 Fig ' 8 is a block diagram showing the VCO control 

methodologies ; 

Fig. 9 is a block diagram showing the terminal 
output control flow; 

Fig. 10 is a block diagram showing the signal 
30 triggering mechanism control flow; 

Fig. li is a block diagram showing the event 
queuing and dispatching control flow; 

Fig. 12 is a block diagram showing the connection 
capability control flow; 
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Fig. 13 is a block diagram showing the capability 
and mode mapping control flow; 

Fig. 14 is a block diagram showing the call 
controller control flow; 
5 Fig. 15 is a block diagram showing the line 

disconnection control flow; 

Fig. 16 is a block diagram showing the line 
dialed, ringback, busy, and connected control flows; 

Fig. 17 is a block diagram showing the line ring 
io control flow; 

Fig. 18 is a block diagram showing the call reset, 
mode setting, and mode restoring control flows; 

Fig. 19 is a block diagram showing the exception 
handling control flow; 
15 Fig. 20 is a block diagram showing the media 

control object command control flow; 

Fig. 21, is a block diagram showing the media 
device capability query control flow; 

Fig. 22 is a block diagram showing the media 
20 access control request control flow; 

Fig. 2 3 is a block diagram showing the device 
event processing control flow; 

Fig. 24 is a block diagram showing the object 
construction and destruction control flows; 
25 Fig. 25 is a block diagram showing the " Open" 

command control flow; 

Fig. 2 6 is a block diagram showing the f Close" 
command control flow; 

Fig. 27 is a block diagram showing the m Call" 
30 command control flow; 

Fig. 28 is a block diagram showing the *Multicall" 
command control flow; 

Fig. 29 is a block diagram showing the "Hang-Up" 
command control flow; and 
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Fig. 30 is a table of the multipoint control 
operations. 

Appendix: contianing source code for Virtual 
Device Interface Header File, 

5 Description of the Preferred Embodiments 

DEFINITIONS 

Provided below are definitions for terms used 
throughout this disclosure. While common technology 
parlance may assign a variety of alternative meanings to 
10 them, those definitions following refer to specific 
usages in this manuscript only, noted explicitly to 
alleviate ambiguous technology references henceforward. 

Transducer 

This term refers to a device that converts one form of 
15 energy into another. Here specific reference is given to 
those that convert light and sound energy to electrical 
pulses, or inversely, electrical pulses back to light and 
sound energy. Examples include cameras, microphones, 
speakers, and video monitors. 

20 signal 

This term refers to a digital data stream used to 
transfer raw or encoded binary information, except in the 
case of direct references to "bit-rate allocation signal 
indications. M 



25 indication 

This term refers to a message connoting a change in state 
or modality of a system or station component; basic unit 
of notification used for the sole purpose of 
communicating the occurrence of some specific event. 

30 Notification 
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This term refers to an indication transmitted from one 
software component in the system to another software 
component in the same system. Typically used to notify 
software system components that some specific event has 
5 occurred and some response is required. 

Spectral information 

This term refers to sound and light data that are 
represented as modulations of electromagnetic or audible 
spectra; audible and visible waveform information. 

10 Binary information 

This term refers to electrical pulse data encoded as 
binary numerical values that are typically referenced in 
octets. 

Terminal 

15 This term refers to as a physical or virtual teletype 

console device that displays text data output to it, and 
returns text input, such as if read from a keyboard 
device; essentially a dedicated text-processing I/O 
device or software representation thereof, with no 

20 significant processing ability. 

Station 

This term refers to an intelligent node on a network to 
which other network nodes can connect and exchange 
messages. 

25 Local station 

This term refers to the station whose resources are 
directly addressable without using an intervening network 
connection; conceptually perceived as the near-end of any 
connection. 
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Remote station 

This term refers to the station whose resources are not 
directly addressable without an intervening network 
connection; conceptually perceived as the far-end of any 
s connection. 

Sharing 

This term refers to bi-directional data transfer between 
interconnected stations on a network. 

Vendor-specific 

10 This term refers to any hardware or software system 
component that requires a non-standardized software 
control layer to accommodate the particular requisite 
interface format and control procedures described by its 
manufacturer. 



15 Multimedia 

This term refers to a class of digital computer 
technologies that store, retrieve, manipulate, and play 
back audible and visual information. These technologies 
are embodied in combined software and digital hardware 

20 sub-systems that encode spectral information presented to 
input transducers, into digital data streams that are 
then stored in a compressed format. This compressed 
digital information is later reconstituted back to 
spectral information by decompressing, decoding, and 

2S subsequent retransmission through output transducers. 

Connectivity 

This term refers to the generalized concept of 
establishing a communications link between two or more 
stations on a network, exchanging messages according to 
30 some preconceived notion of structured interaction; this 
notion of interaction referred to as a protocol. 
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Multimedia connectivity 

This term refers to the generalized concept of 
establishing an audible, and/or visual communications 
link between two or more stations on a network; These 
5 technologies are embodied in combined software and 
digital hardware sub-systems that encode spectral 
information presented to input transducers, into digital 
data streams that are then transmitted across a network 
connection to a remote station in a compressed format • 

10 There it is reconstituted back to spectral information by 
decompressing, decoding, and subsequent retransmission 
through output transducers. When occurring bi- 
directionally in real-time, without delay, the connection 
between the stations is described as " live* , as if the 

is input transducers of one station were connected directly 
to the output transducers of the other, and the network 
becomes conceptually irrelevant to the process* A variety 
of other media forms, such as still pictures and plain 
binary data, may also be exchanged between stations on an 

20 occasional basis, and played back as needed. 

Media Control Interface (MCZ) 

This term refers to a device driver interface 
specification that allows its users to control underlying 
physical media devices using a somewhat well-defined, 
25 standardized string- token command language. 

Media Access Control (MAC) 

This term refers to that set of MCI drivers that provide 
a standardized physical device control interface layer 
between the more device-independent software layers that 
30 issue MCI string commands, and the vendor-specific device 
drivers that contain proprietary interfaces and control 
procedures to initialize, shutdown, and utilize the 
peripheral hardware components. 
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Object-Oriented Design 

This term refers to a methodology to enhance the quality 
of computer systems by describing their constituent 
components as discreet sets of related, well-defined 
operations whose implementations are isolated from their 
functionally described operational profiles; interactions 
between system software components are defined with equal 
precision, according to a specialized software 
development methodology. Highly-structured programming 
languagesl and design tools promote creation of modular, 
reusable software components that can be recombined to 
build new components; existing components are better 
understood in terms of functionality and reliability, in 
this way, implementations of new components borrow the 
is functionality (and demonstrated reliability) of 

preexisting software technologies to create new products, 
thereby significantly reducing development time and 
dramatically improving overall system reliability. 



10 



20 



25 



OPERATING 8YSTEM MODEL 

A more accurate technical description of the VMCS 
is that of a Virtualized Multimedia Connectivity 
Operating System. Designed for a multithreaded, protected 
memory model implementation, the VMCS server component 
runs parallel to the client applications that utilize it, 
the server responding to client requests with a stream of 
notifications directed to class objects located in the 
client programs. A client application invoking a VMCS 
server, spawns a concurrent operating system that 
effectively manages all hardware and software components 
30 necessary to establishing a device-independent multimedia 
connectivity service, in much the same way as any 
operating system does to support its general application 
programs. Once created, the VMCS server runs by itself, 
independent of the client, and capable of offering 
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services to more than one client at the same time. Just 
as with advanced operating systems, the transactions 
between clients and servers are fully protected , and 
highly structured with regards to both syntax and 
5 sequence- The VCO Client selects an "operating system" 
that best suits the system hardware configuration, 
invokes it when needed, discards it when it is no longer 
needed, and changes it when it prefers an "operating 
system" with a different service profile. 

io Consistent with the intention of its design, 

multiple VMCSs can be concurrently invoked. The VMCS, in 
accordance with the "operating system" model heretofore 
described, was intended from its inception, for 
implementation in multiprocessor or distributed systems 

15 where a separate coprocessor, parallel processor, or 
entire system could house the server component 
separately. Further, embedded implementations (for use 
with coprocessor systems) do not pose the usual 
implementation difficulties associated with sub-system 

20 designs whose client and server component were assumed to 
reside in shared memory. 

STANDARDS COMPLIANCE 

There is a well-defined modality of interaction 
between VMCS servers, and the VMCS applications that use 

25 them, the orders of whose operations are specified with 
mathematical precision. Resultantly, there is a high- 
degree of predictability in the progression of 
connectivity sessions, and corresponding measurable 
improvement in their robustness. VMCS implementations 

30 are unique in the domain of multimedia connectivity 

systems. Specifically, they make possible the creation 
of standardized software communication products, enable 
connectivity applications to run over any compliant 
connectivity sub-system, fully integrate audiovisual/data 
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connectivity services into a single control mechanism, 
reduce software development time, and expose 
extraordinary levels of derived functionality. 

This methodology is primarily a software 
development technique. Object-oriented software 
components are created to abstract the low-level services 
of media control and network interface components to a 
fully-virtualized multimedia connection service that 
integrates the ITU-T multimedia interconnection protocols 
(H.320), the Open System Interconnection (OSI) Reference 
Model, and object-oriented software design principles 
The VMCS architecture combines these paradigms into a 
dynamically instantiate client-server multimedia 
connectivity service technology. ITU-T Recommendation 
is H.320 defines a discreet set of operations and procedures 
necessary to the sharing of spectral and binary data 
between compliant interconnected stations. It enables 
reliable, structured data transfer and device mode 
synchronization to. stations connected to the Integrated 
20 services Digital Network (ISDN) . a VMCS implementation 

employs the ubiquitous H.320 recommendation as a rigorous 
definition of its most basic set of multimedia 
connectivity operations. For stations that access the 
ISDN, this application of h.320 is natural and obvious, 
25 but the VMCS goes on to take further advantage of the ' 
apposite H.320 structure. The VMCS architecture insists 
upon the promotion of the H.320 protocol set to that of a 
universal framework to which even non-compliant protocols 
can be promoted. 

30 ARCHITECTU RE! 

OSI REFERENCE MODEL 

Connectivity system developers can abstract the 
presentation of non-compliant services to a 
representation more efficiently managed by applications 
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(that are typically unconcerned with the specific 
requirements of the control mechanisms) . The Open System 
Interconnection (OSI) Reference Model defines a layering 
model offered internationally as a generalized system 
5 architecture to affect the designs of connectivity 
software systems, particularly with respect to host 
stations desirous of reliable interconnection. For any 
host operating system (OS) , a Virtualized Multimedia 
connection System (VMCS) provides an exact definition of 

10 the OSI Presentation Layer that serves as the interface 
between a connectivity application (client) , and the 
connectivity sub-system (server) . The majority of 
software components, common to all VMCS implementations, 
are reusable versions of the services specified to reside 

15 in the OSI Session Layer; they provide device-independent 
implementations of the protocols represented by the H.320 
rubric- Media control and network interface 
manufacturers are usually best qualified to supply low- 
level device/protocol support drivers that comprise the 

20 OSI Transport, Network, and Data Link Layers. The VMCS is 
most efficiently implemented when it leaves this task to 
them, and instead builds on their work- For specific 
media control and connectivity tasks, it is often 
indeterminate as to whether a device, or software 

25 component, will comprise the best utensil. Since the OSI 
Reference Model is functionally specified, a system 
developer has the flexibility to derive a VMCS sub- 
component, or entire OSI Layer, in a way that best 
supports its design specification, regardless of whether 

30 it is build with existing or newly created sub- 
components . 

OBJECT-ORIENTATION 

Both VCO Client and server software components are 
developed with an object-oriented programming language, 



10 



WO 98/09213 

PCT7US97/IS018 



- 22 - 

according to a precisely-defined class inheritance and 
derivation hierarchy. A binary software object is created 
to encapsulate disparate software components into one 
functional entity, whose services are available only 
through structured access of its control elements (member 
functions and member data) . The strategy of all VMCS 
designs, derived by the application of this methodology 
is to encapsulate media control services, connectivity ' 
services, and protocol support components, together i n a 
way that best integrates their properties into an 
instance of a standardized multimedia connection service 
to be used by device- independent client applications 
Specific protocol support procedures, and media control 
components, are shared by all VMCS implementations; 
is usually they are worth preserving, fine-tuning, and 
carrying forward to new implementations. VMCS 
implementations created to support new hardware 
configurations are most accommodating to this 
circumstance, to the extent that they are typically minor 
modifications of a reference VMCS implementation. New 
VMCS implementations may be designed in one of three 
modalities. First, a VMCS can be developed to exploit the 
services of an existing multimedia connectivity product 
(hardware and software sub-system layers) manufactured by 
25 a third party. Such a project would restructure 

proprietary controls of the native interface, coercing 
(virtualizing) them to the structured consistency defined 
by the VMCS paradigm. A second modality is to create a 
presentation of the defined VMCS services for a new 
30 device set, creating all device control components, VMCS 
components, and perhaps the devices themselves. Lastly, 
designs can, at run-time, invoke a particular 
presentation of services, derived from the ad hoc 
association of media control devices with selected 
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connection services, in a way most suitable to producing 
a desired multimedia connectivity service profile. 

CLIENT/ SERVER MODEL 

Notwithstanding the flexibility afforded by 
5 software implementations, it is useful to describe the 
works of the VMCS in terms of discreet, mechanical 
components. There is no requirement for any component to 
be implemented entirely in hardware, or entirely in 
software, per se, so the distinction will not be brought 

10 to bear on this discussion. There are two major 

components in any VMCS: the multimedia connection sub- 
system (server) , and an application program that invokes 
its services (client) . Any VCO Client application can 
invoke the services of any server, without hesitation, 

15 with a guarantee of compatible access. More nebulous is 
the parity between the quality of services requested by 
the client, and those provisioned by physical devices 
encapsulated in the server. Strictly speaking, the server 
is the binary software object that encapsulates the media 

20 control and connectivity sub-system. It is referred to as 
a Virtual Connection Object (VCO) , and the client 
application that invokes usage of its services, is 
referred to as a Virtual Connection Object Client 
Application (VCO Client) . In this section, the scope of 

25 the discussion will be limited to a functional 
description of these entities. 

8ERVER COMPONENTS 

Virtual Connection Objects are binary software 
objects that encapsulate the media control and 
30 connectivity components requisite to the implementation 
of a discreet subset of multimedia connectivity services. 
They are invoked and adjusted by manipulation of their 
members. When constructed, a VCO dynamically builds the 
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particular operational context of hardware and software 
components needed to best implement virtualized 
multimedia connection services. Destruction of the object 
deletes this operational context by shutting down all 
s components, turning off devices, and releasing any 
allocated resources. For the host OS, every 
implementation of such an object presents members that 
are identical in syntax, structure, and usage, in fact 
every VCO is functionally analogous in its control 
10 mechanism, but unique in both its name, and the degree to 
which it is able to realize the full set of VMCS services 
defined to be represented in every instance thereof; that 
is each VCO has a unique set of capabilities. Inherent to 
every VCO, is the ability to provide metrics describing 
is the potential quality of services locally available, and 
the actual quality of services available while connected 
to a particular remote station. The service profile of 
the unconnected local station is available prior to 
device initialization (but after VCO construction) , for 
20 casual examination by interested VCO Clients; this 
profile is referred to as the Local Capabilities. The 
service profile of a remote station is available while it 
is connected to the local station, and this profile is 
referred to as the Remote Capabilities. Also available 
25 when connected, is the service profile of the connection 
itself, referred to as the Connection Capabilities. This 
is the preeminently useful metric, and quantifies the 
potential quality of interactions between the local and 
remote stations; precisely, it is the logical 
30 intersection of the local and remote capabilities. 

A real-time reporting mechanism alerts system 
software objects of changes in the specific states, 
modalities, and conditions critical to the operation of 
the encapsulated multimedia connectivity sub-system. The 
35 basic unit of information, or indication, is referred to 
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as an Event, and each VCO contains a specialized delivery 
system that can notify software components in the host 
system when one such event has occurred; a Notifier 
Object is the mechanism for this delivery. Notifier 
5 Objects are triggered by the occurrence of any event type 
to which they are programmed to respond, and they are 
used both internally by the VCO, and externally by its 
clients. Finally, it should be pointed out that a VCO is 
implemented to present the services of one particular 

10 configuration of media control /network interface setup 
that comprises the multimedia connectivity sub-system, 
and it is likely each significantly different hardware 
and/or software configuration will require a somewhat 
different VCO implementation; a VCO is a device-dependent 

15 entity. 

CLIENT COMPONENTS 

Applications programs described in the VMCS are 
referred to as Virtual Connection Object Clients, are 
device- independent, software application programs that 

20 invoke VCOs, and manipulate their members to control live 
information-sharing sessions with remote stations; to 
that end, they create use-specific logical combinations 
of currently available audiovisual/data resources to 
support a defined set of multimedia connectivity tasks 

25 that is the embodiment of that particular connectivity 
application. They are developed in an apriori fashion, 
according to a concise, multimedia connectivity software 
control interface specification, the integral 
implementation of which each VCO must contain. Clients 

30 dynamically invoke at least one appropriate VCO, selected 
(from a library) according to some notion of suitability, 
and then construct it only when a connectivity session is 
actually to be initiated. VCO Clients create instances of 
Notifier Objects, and utilize them as a mechanism to 
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respond (more-or-less instantaneously) to occurrence of 
divers events to which they have been rendered sensitive. 
A client software object that contains member functions 
to receive, and respond appropriately to, these signaled 
events, is referred to as a Notification Receiver Object. 
Clients may monitor and/or intercept connectivity and 
device control related occurrences in the encapsulated 
sub-system, by creating- instances of vco Notif ier Objects 
with specific response profiles. These Notif ier Object 
response profiles may be reconfigured ad hoc; they define 
the set of specific events that will trigger 
notifications (when a specified event occurs) to one 
identified NRO. There can be only one NRO associated with 
a particular instance of a Notif ier Object. In a given 
host OS, any VCO Client can function using any VCO; a VCO 
Client is a device- independent entity. 



METHOD 

Here follows description of a method to implement 
a preferred embodiment of a Virtualized Multimedia 

20 Connection System (VMCS) . The scope for the disclosure 
will be restricted to an elucidation of those elements 
required to derive a design specification for a fully 
device-independent multimedia connection system; a system 
to be built from third-party media control devices, 

25 device drivers, and a connectivity protocol stack running 
over a network interface unit. All VMCS software 
components are created with an object-oriented 
programming language (see M.A. Ellis and B . Stroustrup, 
The Annotated C++ Reference Manual, Reading, 

30 Massachusetts, Addison-Wesley , 1990). Attendant source 
code provides a precise definition of the host/client 
software interface, and an example of a simple, portable 
device- independent connectivity application. 
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The design of this system will be considered 
initially from the perspective of an overview, and 
subsequently as a functional examination of its component 
interwprkings. Next comes a detailed examination of 
5 critical software and hardware constructs needed to 

physically implement a VMCS design. The topic concludes 
with a discussion related to the deployment of a working 
system in an actual host computer system. For this 
section in particular, the examinations of system details 

10 remain more generalized in the start, and are more fully 
later resolved, the strategic intention to permit a 
system engineer to pursue a top-down design approach for 
his particular VMCS adaptation. Compliant designs will 
produce products supporting exact binary compatibility 

is between every VMCS created for the same target operating 
system, and exact functional compatibility between every 
VMCS, regardless of the target operating system. 

DESIGN 

VISUAL TELEPHONE SYSTEM MODEL 

20 The creation of a visual telephone system is the 

most likely application for a VMCS implementation. Such 
a system illustrates all of the basic components that 
comprise the set of media control, network interface, and 
software control features common to most such solutions 

25 now available. The ITU-T describes a generalized model 
for this type of system in a document referred to as 
Recommendation H.320. This discussion, as related to a 
VMCS implementation, is best served by a similar 
treatment of the subject, as it relates to the task of 

30 deriving a virtualized model of multimedia connectivity; 
the VMCS software abstraction represents the functional 
aspects of the generalized visual telephone, with some 
notable extensions to its base level utility. It must 
also be pointed out that a VMCS implementation in no way 
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relies upon the ITU-T recommendations below the level of 

the signal and indication protocols specified by H.320 

any network or connectivity sub-system could conceivably 
be adapted as the underlying network transport layer. 

5 ELEMENTS OP A VISUAL TELEPHONE SYSTEM 

The prototypical VMCS system relies on divers 
hardware and software components to transfer audio, 
motion-video, still pictures (images), and binary data 
objects between stations connected to the same network. 

10 Devices and control systems described below should be 
considered in terms of being functional entities; the 
potential to support device characteristics with a 
software emulation module is an implementation 
alternative that does not alter the basic strategy of 

is VMCS design. In fact, input from, or output to a 

transducer device can be simulated by a data stream read 
from, or written to backing store. 

I/O Equipment 

These devices are referred to as transducers in 
20 that it is their primary task to convert energy forms 
from spectral to pulsed electrical, or vise-versa, in 
practical terms, these devices are the only parts of the 
system with which the user interacts directly. 

• Audio devices include stationary microphones 
2S and related sound detection eguipment to 

input the voice of the user. For output, 
loudspeakers and headphones are output 
transducers in a VMCS. 

• Video devices include a camera to input 

30 motion-video images of the user. For output, 

video monitors display motion-video, as do 
dedicated analog (NTSC/PAL) video displays 
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• Image devices include a camera to input 
images, as well as scanners to capture high- 
resolution images. For output, video monitors 
display images, and in addition, printers 

s that can render images are considered output 

transducers . 

• Data devices do not convert energy forms, but 
are essentially "locations" in the system 
through which data flows, or in which it is 

10 stored. Data devices include any backing 

store (disk) entities, or data ports, such as 
a communications port. Dedicated data 
streams, or "socket" interfaces would also 
qualify as valid VMCS inputs /outputs for 

15 binary data. 



CODEC 

These devices compress data from input transducer 
devices prior to transmission or storage, or inversely 
decompress data following transmission from a remote 
20 station or retrieval from storage. The process of 

compression is referred to as encoding, as spectral data 
is encoded according to an algorithm; decompression is 
correspondingly referred to decoding. Visual telephones 
transmit and receive audio and video data in a compressed 
25 format so as to enhance the efficiency of the system in 
its endeavors to exchange large volumes of audio and 
video data across connections that only support a very 
limited bandwidth. Storage of images to disk proceeds in 
the same way to reduce the amount of storage space 
30 required. 

• Audio da/ compression devices are typically 
incorporated together with H.221 
encoding/decoding hardware used for video 
processing; audio compression and 
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decompression are often accomplished in 
software. 

• Video de/compression for live motion-video 
conferencing is best accomplished with 
hardware specifically designed for H.221 
encoding/decoding; video compression in 
software (for high quality video) is 
typically unsatisfactory. 

• Image de/compression for images is typically 
done in software according to a specialized 
algorithm (such as JPEG) or transmitted as a 
simple bitmap. 

• Data de/compression is typically not 
required, save only when the data object 
itself has been compressed prior to 
transmission, as part of a separate 
operation. 

Telematic Equipment 

These are facilities (devices or software 
components) that act a visual aids to enhance 
conferencing. Application sharing features, common 
whiteboards, and image transceivers are included in this 
category, as are scanners and facsimile devices attached 
to communications ports on the visual telephone station. 

Multiplexors/Demultipiexors 

Signal multiplexing and demultiplexing operations 
are typically combined into a single hardware device that 
combines the audio, video, and related data streams to 
the single H.221 frame structure (multimedia signal) used 
in line transmission, and restores them to their 
constituent data streams upon receipt from a remote 
station or storage entity. 
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Network interface 

This component is typically a hardware device that 
provides the physical connection between the host station 
and the network, though software simulations may provide 
5 an emulated version of the same* 

Network 

Any transport medium supporting actual or emulated 
line transmission of the H.221 signal and indication 
portion of this protocol, and capable of synchronous (and 
10 simultaneous) audio, video, and binary data transport. 
Examples of recommended network types include the 
following: 

• ISDN (Basic and Primary Rate Interfaces) 

• B-ISDN (Using ATM) 

15 • LAN (FDDI and high-bandwidth proprietary 

technologies) 

• Mobile/Radio (and other wireless) 

• Analog (PSTN) 

Multipoint Control Unit 

20 This is a specialized device whose functionality 

is described by ITU-T Recommendations H,243 and H.231. 
The functionality of this device must be available for an 
implementation of a VMCS that is fully capable of the 
entire set of VMCS-defined multipoint control operations. 

25 System Control 

The VMCS is an implementation of this (system 
control) visual telephone system component, but conceived 
as a more generalized model suitable for utilization in a 
broad range of concurrent audiovisual/data sharing 
30 applications. The VCO component of the VMCS allows a 
device-independent connectivity client application to 
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utilize any audiovisual device control system services 
related to those of the defined visual telephone system. 

VISUAL CALL PROGRESSION 

A VMCS session takes the form of a visual 
telephone call. This interconnection procedure is 
precisely defined, and permits interoperability between 
dissimilar stations sporting diverse equipment 
complements, while retaining compliance to ITU-T 
Recommendation H.320. it would not be possible to utilize 
the plethora of potential operating modalities of VMCS 
systems without a thorough categorization of the set of 
all those modalities known to be supported by the local 
station's equipment configuration. Further, each station 
participating in a connectivity session (call) must come 
15 to an understanding of the modalities supported by its 
counterpart at the other end of the connection. What 
ensues at the time of the call is a planned negotiation 
that pats the performance expectations of the local 
station (as to the set of operating modalities it would 
20 ideally prefer to assume during the session) , against the 
cataloged limitations of its remote station peer; a 
common set of operating modalities they both must co- 
operatively determine and ultimately share for effective 
audiovisual communication. 

25 Establishment of visual Telephone Call According to H.320 

Shown below are the basic steps common to 
establishing a "normal" visual telephone call. This 
sequence is idealized in that it does not suffer 
interruption or complication as frequently occurs in 
30 actual use. Notwithstanding the inevitable anomalies 

encountered during live operation, the following sequence 
provides a model for call progress; one that must be 
implemented by every VMCS connectivity sub-system, and 
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one derived directly from the ITU-T visual telephone call 
procedure as follows: 

1) Call setup, out-band signaling (H.200) 

A request is made to the network for a 
5 connection to a remote station. Indication is 

received at both ends to indicate when this has 
occurred, and a bi-directional data channel from 
end to end is opened for use. This data channel 
carries multiplexed multimedia data between the 

10 stations. A device-independent call control 

mechanism is integral to all VMCS server 
components (Virtual Connection Objects) and 
operates directly to manage the call states and 
related operations required to create the 

15 connection and data channel. 

2) Mode initialization on initial channel (H.242) 

An exchange of device capabilities takes 
place once the connection is created and frame 
alignment for the data channel is achieved. It is 
at this time that the VCO call controller 
initiates sending its own capabilities to the 
remote station. It also receives and stores 
-capabilities sent from the remote station. A 
common base-level audio mode is selected. by the 
stations according to availability indicated by 
the exchanged capability sets. In the VMCS, any 
connection established must engage in the exchange 
(or emulate the exchange) of a capability set. A 
minimal bi-directional data channel must also be 
established in this phase. A capability exchange 
between stations can be initiated from either end, 
and may reoccur at any time (while connected) to 
assert a new ability recently assumed by a 
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station; a device may be turned on or off during 
the session, thus changes the stations capability 
profile. 

3) call setup of additional channels (if used) 

s Though not always used, the VCO supports 

connections of two separate lines. While network 
configurations may use six or more separate lines 
for a call, they are typically bonded together as 
one call and thus appear as a single line call to 
10 system call control. Call setup for additional 

lines proceeds in an identical fashion to that for 
the initial channel. 

4) Initialization on additional channels (if 
used) 

15 Though only used if additional channels have 

been established, capability exchange and mode 
selection proceeds as for the initial channel. 

5) Establish common parameters (H.242) 

Both stations have available a list of the 
20 other's capabilities. Each VMCS has associated 

with it, a specific conference profile parameter 
that is used to specify the operators preferred 
operating properties. Examples include a bias 
towards better video guality, or better audio 
25 guality. Coupled with this profile is a set of 

operating modalities that can be supported by both 
ends of the connection, and the preference of the 
remote operator. According to the physical 
limitations of the remote station's device 
30 capabilities, and in hopeful compliance with the 

preferences of the operator, a device mode 
negotiation mechanism seeks to algorithmically 
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deduce the most suitable set of device modes for 
the call by interacting with the remote station to 
realize them. 

6) Visual telephone communication (H.261) 

5 This phase refers to the fully established 

session itself, whereby audio, video, and binary 
data exchange can take place over existing data 
channels. The H.320 Recommendation states that 
visual and audio communications must be active in 
10 this phase, though the VMCS allows for idle 

connections during which time no data exchange 
takes place; that is audio and video may be 
disabled, while the connection is still 
technically active. 

15 7) Termination 

When one user hangs up, an indication is sent 
to the other end to signal termination of the 
call, in the form of disconnection signals for all 
lines. Such action by one end, initiates the call 
20 termination process; the initiating station shuts 

down all of its data transmission to the remote 
station. Out-band signaling is typically used for 
the purpose of disconnection. 

8) call release 

25 Once termination has been initiated (when the 

other end receives this message) the station sets 
data transmission to idle for each disconnected 
channel. When all lines in the call have received 
disconnection events and been set to idle, the 

io call is considered to be disconnected. Individual 

lines can be added or removed as needed, without 
disconnecting the entire call. 
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VMCS SYSTEM OVERVIEW 

FIG. 2 depicts an overview of the major components 
of a Virtualized Multimedia Connection System. There are 
four significant entities shown: The Virtual Connection 
5 Object (VCO) , the Virtual Connection Object Client 

Application (VCO Client) , I/O devices, and the network. 
The VCO and the VCO Client are the subject of this 
disclosure. The I/O devices are connected with a direct 
physical link to adapter boards in the host system that 

10 permit the physical control of the I/O devices via device 
driver. Essentially, the only link the VCO has to these 
devices is through a vendor-specific Media Access Control 
software layer (or some other device driver) , and the VCO 
link to the network interface unit is through a 

is standardized, or vendor-specific network protocol stack. 
The network protocol stack shown in the drawing is likely 
some OSI Transport Layer abstraction of a connection 
service. 



Summary of VMCS System Overview 

20 From a conceptual standpoint, the VCO combines the 

services of the data transfer (network) service with 
associated media transducer devices, so as to reliably 
offer system command and control of a derived multimedia 
connectivity service to an application program. There are 

25 two primary components of any VMCS; they are as follows: 

• The Virtual Connection Object (VCO) 
encapsulates all of the server components 
that are required to abstract a virtualized 
representation of the media control and 

30 connectivity sub-systems, offering it to 

device-independent connectivity clients. 

• The Client Application (VCO Client) 
constructs and utilizes the virtualized 
multimedia connection services hidden away 
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inside the VCO by manipulating its member 
functions and member data. There are a number 
of specific objectives motivating this 
object-oriented system design, the substance 
5 of which receives commentary below: 

System Design Objectives 

Design-level Support for VMCS Services 

The objective of the VMCS design is to provide 
design-level support for a full virtualization of any 
10 multimedia connection system, so that device-independent 
representations of a logical control mechanism could be 
ported to a wide variety of supporting media control 
devices and network interface- Client applications 
designed to utilize VMCS technology are interoperable 

15 with every VCO implementation (running under the same 
operating system) and thus more efficiently distributed, 
maintained, supported, and redeployed with new device 
complements. Most important is the ability to bind any 
network interfaces to any media control interface by the 

20 addition of specialized hardware and software layers that 
combine the functions of these components without 
affecting its mechanism of control. New and different 
underlying technologies are well utilized, however the 
extensible VMCS virtualization paradigm leaves their 

25 often peculiar operating procedures fully obscured from 
the view of application programs. 

Progressive Isolation of Sub-system from Applications 

The VCO component of the VMCS incorporates a 
number of design methodologies whose purpose is to 
30 dissociate the control of services, from their physical 
implementations. The Open System Interconnection (OSI) 
Reference Model (see B. Hebrawi, OSI Upper Layer 
Standards and Practices, New York, NY, McGraw-Hill, 
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pp. 11-15, 1993) and object-oriented programming languages 
are primary building blocks in any VMCS. 

• OSI Layering underpins the structure of the 
VMCS in that the VCO is a logical 

s encapsulation of all of the OSI layers below 

the presentation layer. The VCO members 
themselves comprise the OSI Presentation 
Layer implementation, whereas device- 
independent routines in the upper VCO layers 
10 form a discreet and reusable OSI session 

layer. 

• Class Structure of the VCO is rigidly defined 
so as to preserve the largest number of 
functional source components from 

15 modification, and to maintain the design 

integrity of the VMCS. Class components 
allow for a definitive specification of 
distinct, isolated functional units that will 
not affect their interactions with related 

20 components when their internal 

implementations have been modified to 
accommodate the operational characteristics 
of vendor-specific components. 

• Discreet Member Profile preserves the 

25 modality of the interface that makes each and 

every VCO implementation appear the same to 
clients, and consequently it is most 
essential to maintain its form to enable 
interoperability for all clients. VCO 

30 Clients assume that the specific member 

profile of every VCO is identical, thus each 
can be invoked and utilized without concern 
for incompatibilities between them. 

• Token-based Job Description Language is a 
35 text-token representation of the VCO member 
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functions and their highly structured 
enumerated arguments. If the structure of the 
VCO interface is consistent (over time) and 
reducible to simple string commands, then it 
5 is possible to reduce the control of any VCO 

to a series of text messages in a character 
stream. From this approach is derived the 
capacity to remotely control a VCO. User 
applications are almost entirely isolated 
10 from the server component in that each server 

(VCO) functions as a command interpreter. 

Client Components 

The VCO client in FIG. 2 is a device-independent 
layer that is dynamically portable at run-time to other 
is VCO-encapsulated multimedia connectivity sub-systems. All 
VCO Clients are fully interoperable with all server (VCO) 
layer components that offer a consistent presentation 
(OSI Presentation Layer) constructed according to an 
interface specified in this document. Notification calls 
20 from the VCO to the client can occur spontaneously, 
asynchronous with other system events, and concurrent 
with notifications emanating from other VCOs invoked by 
the same client, thus most client modules should be 
designed to support re-entrancy and mutual-exclusive 
25 access to resources. A multithreaded implementation 

strategy is most efficient to manage the various, often 
concurrent tasks related to simultaneously maintaining 
the visual information presented to the user, and 
supporting the command, control, and real-time monitoring 
30 of the multimedia connectivity sub-system. Regardless of 
the frequency of device interrupt requests or the rate of 
message passing between interconnected stations, the flow 
of notifications from the VCO to the client is conducted 
according to a dynamically configurable interval that a 
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client can optimize according to its particular needs. In 
reality, the client runs at operating system speeds 
determined by the system scheduler, while low-level 
device control components in the VCO run at device speeds 
5 determined by the network and the devices themselves. 
Resultantly, VMCS systems share the following 
characteristics : 

• Applications can vary the periodic rate at 
which they are actually notified of device 

10 events occurring sporadically, in real-time 

• Applications never miss events, and are never 
unable to respond to them due to their 
occurring in time slices not allocated to the 
application. The VCO notifies its client 

15 application that a particular event has 

occurred, by scheduling the application to 
run, in response to that event, on a special 
thread created by the VCO event dispatcher. 

• Application processing of device events 

20 catches up to the rate at which the device 

produces them, by continuing to send 
notification of events to the application 
during I/O latency periods when the device is 
less active. 

25 • Critical section handling, as related to 

device interrupts and the management of 
device driver queues, is fully managed by the 
VCO, thus the application may process 
notification events at a high-level; it is, 

30 by design, nearly impossible for an 

application to corrupt the timing and real- 
time operation of the low-level device 
control sub-system. The application sees 
these sub-systems as a stream of interesting 
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events, none of which requires attention for 
proper VCO operation. 

Application Shell 

The application shell is preferably an event - 
5 driven graphical user interface (GUI) program written in 
an object-oriented programming language. There are no 
special considerations for VMCS integration. Retrofitting 
of existing GUI programs, to work as VCO Clients, is 
easily accomplished. In fact, any application shell that 

10 constructs a VCO is defined as a VCO client, and only a 
modicum of member functions need be called to establish a 
fully operational connectivity session to a remote 
station. A daemon that constructs a VCO, and fields 
string commands from a hardware or software data port, 

is can serve as a non-interactive VCO client. 

Notification Receiver Objects (NRO) 

These software objects are created to provide a 
structured mechanism for responding to VCO events. Any 
application class object can contain a specific member 
20 function and adjunct function mapping component to direct 
the VCO to send a notification message to that object 
upon the occurrence of any set of specified events. 

VCO components 

The VCO utilizes a three-layer software design 
25 that converts the native modalities and properties of 
some set of physical devices to those that can be 
accurately described using the parameters specified by 
the VCO. Underlying the software components are device 
control components used to physically operate the media 
30 control and connectivity sub-systems. These low-level 
components, and the devices that they control, are 
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typically provided by a third party specializing in their 
respective technologies. 

Virtual Device Interface (VDI) 

Provides a logically-defined, or virtualized 
s interface to services that would be offered by an 
idealized, functionally advanced combination visual 
telephone/imaging system. The VDI is a reusable shell 
that is common to all vco implementations (in a given 
OS) . 

10 virtualization Layer (VL) 

Translates logical operations defined in the VDI, 
to physical implementations (of those most similar) 
provided by the PDI. The VL is set of mostly reusable 
routines that are, as needed, partially reimplemented to 
15 work with a particular device set in the PDI. In many 
cases, VL components may include direct accesses to 
vendor-specific connectivity protocol stacks and media 
control components. 

Physical Device Interface (PDI) 

20 Provides a physical, or driver-level interface to 

actual physical devices assigned to the control of the 
VCO implementation. The PDI inherits virtualization 
functions from the VL to provide a rigidly compliant 
implementation of a device control interface used by the 

25 VDI directly to provide support for its logically defined 
tasks. Pbl implementations include direct accesses to 
vendor-specific connectivity protocol stacks and media 
control components. 



30 



Encapsulated Devices 

The encapsulated devices in a VMCS typically 
include a network interface unit and a host of related 
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media control devices. The connectivity protocol stack 
refers to the software layers necessary to provide 
services defined for the OSI Transport Layer; that is, it 
must ensure the reliable transfer of messages between end 
5 users. Media Access Control must contain drivers enabling 
physical operation of all devices relegated to VCO 
control, as previously specified in the section entitled 
DEFINITIONS. The types of devices likely to be 
incorporated into the VCO design, will be some variation 
10 upon those described to manage audio, video, images, and 
binary data, as specified in the section entitled I/O 
Equipment. 

Component Interactions 

There are well-defined modalities of interactions 

is between VMCS components. The VDI makes direct use of PDI 
members to invoke the services of physical devices in its 
mission to fulfill VCO Client requests for services. The 
PDI, in turn, calls functions in the connectivity 
protocol stack and in the Media Access Control layer. The 

20 PDI calls member functions in the VL to provide the 

mapping, translation, and formatting necessary to coerce 
the low-level services to resemble those logically 
specified by the VDI. As they occur in real-time, events 
generated by the connectivity protocol stack and Media 

25 Access Control components are added to a general VCO 
event queue. A dispatcher in the VCO removes events 
periodically, synchronous with the operating system 
scheduler. An event processor in the VL responds to 
events as they are dispatched to it, invoking other VCO 

30 components as needed. Some of these events require that 
the client application be notified of their occurrence, 
if the client has so arranged. 
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VCO ARCHITECTURAL OVERVIEW 

FIG. 3 depicts a functional block diagram of a 
VCO, with components partitioned according to the VCO 
layer where they reside. This section provides a high- 
level view of the VCO sub-components' functional 
organization. Subsequent sections pursue a more rigorous 
examination of the constructs themselves, here only 
topically considered. It is more important to note that 
the VDI, VL, and PDI sections labeled "Device /Protocol 
Controllers" are to be considered as layer-specific 
overlays of the same groups of components. The groups in 
the VDI section "Device/Protocol Controllers" illustrate 
the logical definitions for each of ten distinct 
functional categories; corresponding groups in the VL and 
PDI describe the identically functional categories, but 
at a different level of software abstraction. All 
components in the VDI section are fully reusable, device- 
independent software components. Those components in the 
PDI are vendor-specific and implementation-specific while 
those in the VL are mostly device- independent , but may 
require some implementation-specific coding to support 
wide variations in the underlying device control 
software. 

Software components in the VCO are physically 
divided into very specific object entities, each of which 
much interact with those adjunct and adjacent. A set of 
related functions and data structures combine 
synergist ically, are referred to as a controller. Such 
entities are the basic functional units of the VCO in 
that they form discreet functional "parts" that control 
and/or manage a well-defined set of tasks. 

Summary of VCO Architectural Overview 

The VCO is a single binary software object that 
encapsulates all of the hardware and software components 
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necessary to implement a fully Virtualized Multimedia 
Connection System. Virtualization of the services 
provided by disparate connectivity and media control 
systems is rendered according to three-layer progressive 
5 abstraction strategy that relies upon object-oriented 
software technology for both its design and 
implementation. 

• A device- independent, reusable software 
layer call the Virtual Device Interface (VDI) 

io is created to provide a detailed logical 

description of a virtualized multimedia 
connection service. It has as set of public 
member functions that define its interface to 
applications and other invoking software 

is modules. Included in this layer are a series 

of software controllers that are specifically 
here located (in this logical layer) to 
embody the larger part of the system' s 
software implementations in a layer that 

20 would be directly propagated to new system 

implementations, wherefore to facilitate the 
creation of a highly reliable, reusable, 
portable modules. 

• A mostly reusable, and predominantly device- 
25 independent intermediary software layer 

called the virtualization Layer (VI^ is 
created to assist in the process of 
translating and mapping the functions of 
various device control mechanisms employed by 
30 the underlying connectivity and media control 

sub-systems, to the logically defined virtual 
representation required by the VDI. 

• A device-dependent layer called the Physical 
Device Interface (PDI) interfaces directly to 

35 the device control sub-system to provide a 
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physical implementation to the service 
requested by the VDI . The PDI makes use of 
virtualization functions in the VL to coerce 
the particular message and data output 
s formats of vendor-specific device control 

components, to a structured format integral 
to the VCO design. 
• Audiovisual and binary data streams in the 
PDI sub-system are represented as Media 
10 Control Objects (MCO) . A list of these 

objects is maintained by the PDI so as to 
present the VCO with a pool of available 
media device and signal resources. According 
to the media type, and its direction of flow 
15 in the system, these MCOs are classified 

accordingly as either an audio, video, image, 
or binary data type. They are further 
characterized as a signal from the remote 
station, to the remote station, to a local 
output device, or from a local output device. 
Operations performed on these objects modify 
their properties and modalities of 
interaction, so as to provide the VCO with a 
logical software switching mechanism for its 
encapsulated media control device inputs and 
outputs . 

Virtual Device Interface 

The device- independent portion of the VCO, is a 
fully reusable entity that is created once, and then 
propagated to all VCO implementations. It contains the 
definition of all the VCO public member functions 
accessed by clients. These members are collectively 
referred to as the Software Control Interface (SCI) , 
which itself includes a number of other VCO control 
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mechanisms whose functionality extends well beyond simple 
calls to members. The VCO event notification mechanism 
and terminal stream I/O manager are integral to the VDI, 
as are ten controllers related to implementation of the 
s services requested through calls to SCI members. 

Software Control Interface Functional Groups 

These groups of "control members" contain the 
member functions used by clients to invoke VCO services • 
Each relates to a set of public VCO member functions used 
10 to access a specific class of well-defined operations. 

• Event Notification Control Members enable the 
creation, deletion , and configuration of 
"Notifier Objects" (NO) that may be 
programmed to trigger on the occurrence of 

15 any one of a defined set of VCO events. When 

a Notifier Object triggers , it make a 
function call to a special member function of 
a specified object, and thereupon conveys 
information concerning the event that 

20 occurred. 

• Configuration/System Setup Control Members 
enable VCO configuration information to be 
saved to, or retrieved from backing store. 

• Terminal Services Control Members enable 
25 writes of text messages to VCO terminal 

output port, and command input through the 
VCO terminal input port. They also allow the 
VCO terminal output port to be attached to 
various output devices. 
30 • Network Session Control Members enable 

establishment of a network session with a 
remote station. They include members to 
invoke initialization and shutdown of the 
physical device control sub-system, as well 
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as to place point-to-point and multipoint 
calls. 

• Audiovisual/Data Signal Switching Members 
enable signals to/from the remote station, 
and to/ from transducers to be manipulated, 
combined, and interconnected in various 
combinations . 

• Binary Data Object Exchange Control Members 
enable buffers, files, and other binary data 
entities to be transferred between the local 
and remote stations. 

• System Information Store/Retrieve Control 
Members enable access to VCO parameter blocks 
containing information about their 
encapsulated devices, current call states, 
protocol states, configuration, and 
control/monitoring context. 

• Protocol Management Control Members enable 
direct manipulation of the H.320 protocol 
whose implementation is integral to the VCO. 
Allows advanced operators to perform mid- 
level operations to configure the VCO, and 
any connected remote station, according to 
the procedures of H.320. 

25 Notification Controller 

This notification mechanism is used both 
internally by the VCO, and by client applications that 
wish to monitor, or respond to specific system events. A 
Notifier Object is created, and programmed to respond to 
30 any subset of the cataloged VCO events. If the event 

occurs, a special notification member in a target object 
is called and passed information regarding the occurrence 
of the event. The Notification Controller refers to all 
of the member functions and member data necessary to 
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implement the notification mechanism in each VCO. It 
contains three distinct parts that operate both 
independently and together, depending on the notification 
task at hand. 
5 • Notification Triggering Mechanism is 

responsible for determining exactly when a 
Notifier Object should trigger, by examining 
its list of triggering events when one such 
event occurs. If the Notifier Object is set 
10 to trigger on the event, it is activated to 

initiate its trigger sequence, thereupon 
informing a specified software object that 
the event has occurred; it passes parameters 
during a call to a notification member 
15 function. 

• Notifier object List Manager is responsible 
for creating, deleting, modifying, and 
querying a database containing all Notifier 
Objects for the VCO. 
20 • Linked Notifier Object List is a doubly 

linked list of all Notifier Objects for a 
VCO, and it is maintained by the Notifier 
Object List Manager. 

Terminal stream Controller 

25 This terminal stream mechanism is used both 

internally by the VCO, and by client applications that 
wish to direct streams of text messages to a configurable 
set of terminal output port destinations that may include 
files and system character devices. Alternately, streams 

30 of text messages directed to the VCO terminal input port 
are interpreted as VCO commands and invoke standard VCO 
operations. This Terminal Stream Controller refers to all 
of the member functions and member data necessary to 
implement the terminal stream I/O mechanism in the VCO. 



WO 98/09213 

PCT/US97/IS0I8 



IS 



- 50 - 

It contains three distinct parts that operate both 
independently and together, depending on the terminal 
operation. 

• Terminal stream I/O Device Controller is 

S responsible for processing text messages sent 

to the VCO terminal input and output ports, 
in addition to managing the list of i/o 
devices . 

• Text Command Encoder/Decoder is comprised of 
10 two separate components: the encoder portion 

converts calls to the SCI into text-token 
string command representation used for remote 
VCO control, and the decoder parses an input 
stream of such text-token string commands and 
makes calls to the SCI as indicated by their 
format. 

• Linked Terminal stream I/o Device List is a 

doubly linked list of all terminal I/o device 
objects that describe the identity and status 
for all character stream files, and devices 
to which text messages sent to the VCO 
terminal output port are written. 

Device/Protocol Controllers 

This group of controllers serves to support the 
implementation of the logical operations invoked by calls 
to SCI member functions, as well as providing 
implementation of operations necessary to the 
establishment and maintenance of a connectivity session. 
The implementations of services in this VDI component 
30 must be only that portion of the given operations that 
can be supported in a fully device- independent manner. 

• Object Construction refers to all procedures 
and data structures involved in the 
construction of the VCO, including 
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initialization of all object software 
components that do not control devices* 
Provides direct support for operations 
invoked by construction of the VCO by a 
client application. 

Object Destruction refers to all procedures 
and data structures involved in the 
destruction of the VCO, by its client 
application, including shutdown of all object 
software components . 

Conf i guration /System setup refers to all 
procedures and data structures involved in 
configuring the VCO according to its profile, 
previously saved on a backing store device. 
Also includes support for specialized audio, 
video, image, and binary data equipment setup 
utilities. Provides direct support for 
operations defined for the SCI 
Configuration/System Setup Members. 
Binary Data Object Exchange refers to all 
procedures and data structures involved in 
the transfer of named binary objects, such as 
system files, to and from the remote station. 
Provides direct support for operations 
defined for the SCI Binary Data Object 
Exchange Control Members. 

Network Call State refers to all procedures 
and data structures to support a call 
controller compliant with that described in 
the section entitled Visual Call Progression, 
and consequently function to establish and 
maintain the connectivity session with the 
remote station. Provides direct support 
operations for internal VCO connectivity 
sessions . 
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System Information refers to all procedures 
and data structures involved with storage, 
retrieval, and maintenance of the various VCO 
parameter blocks, and their associated tables 
and lists. Provides direct support for 
operations defined for the SCI System 
Information Store/Retrieve Control Members, 
capability Exchange refers to all procedures 
and data structures needed to support a 
structured exchange and comparison of device 
capabilities, as described in the section 
entitled Visual Call Progression. Provides 
direct support operations for internal VCO 
connectivity sessions. 

System Exception refers to all procedures and 
data structures involved in handling fatal 
errors that may occur in the VCO. Provides 
direct support for operations defined by SCI 
VCO Settings Members not shown in the 
drawing. 

Media Control Object Access refers to all 
procedures and data structures involved in 
accessing the object-based device control 
system implemented in the PDI. Provides 
direct support for operations defined for the 
SCI Audiovisual/Data Signal Switching Control 
Members (that are not shown in the drawing.) 
Protocol Mode Negotiation refers to all 
procedures and data structures involved with 
establishing a common set of parameters 
between the local and remote stations as 
described in the section entitled Visual Call 
Progression. Here also lies support for 
operations that will affect a specific 
conference profile as specified by the VCO' s 
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configuration parameters (or as set by the 
client application) ; includes support for 
operations essential to internal VCO network 
session implementation. 

5 Virtual! zat ion Layer 

Contains all procedures and data structures used 
to convert vendor-specific formats to those defined by 
the VCO. This layer also contains a number of controllers 
that are not always able to be implemented in a device- 
10 independent fashion, as some cognizance of vendor- 
specific peculiarities is frequently necessary to create 
a functional virtualization service layer. 

Event Controller 

Assigned responsibility for modulating the flow 
15 rate of device and software-generated events, in and out 
of an event queue. The queue acts a storage repository to 
record both the progress of operations carried forth by 
the VCO, as well as reports of new states and modes 
assumed by its underlying real-time device control sub- 
20 system. In general, devices and VCO controllers perform a 
mutually exclusive addition of events to an infinite 
sized event queue, in real time. A dispatcher removes 
them at a regular periodic rate, and disseminates them to 
an event processor, and to client applications desirous 
25 of knowing that one (of a particular set of events) has 
occurred . 

• Event Processor provides a structured 
mechanism for the VCO to respond 
appropriately to events generated by its 
30 device control sub-system. It maintains a 

number of feedback loops and procedures that 
are critical to enabling the VCO to 
adequately monitor and control its 
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connectivity session without assistance or 
monitoring by the client application. 
• Periodic Event Dispatcher checks the vco 

event queue at regular intervals to determine 
s if it contains any events. If there is at 

least one event in the queue, the dispatcher 
removes it (a single event) and invokes the 
Notification Controller to trigger any 
Notifier Objects that may be configured to 
10 respond to that event. 

• Infinite fipo Event Queue provides a 

sequentially-ordered cache for all events 
emanating from the device control sub-system 
or for events generated by software 
15 components within the VCO. It operates 

according to the first- in-first-out algorithm 
so that the original sequence at which the 
events occurred, is preserved through the 
event processing stage. Since the queue is 
!0 constructed as a linked list of event 

records, it is capable of growing to a size 
limited only by the availability of system 
memory; thus events are never lost in any 
VMCS. 

5 • critical section Handler provides a mechanism 

to add events to the event queue in a 
mutually exclusive fashion. Also, various VCO 
operations that could result in resource 
contentions and deadlocks can utilize this 

0 component . 

Linguistic Controller 

Assigns textual labels to VCO events, states, 
operations, and a host of other functional entities, in a 
way that describes them using plain language. The role of 
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this controller is to enable VCO components to report the 
status of their operations in a readily-understandable 
format, rather than by the encoded strategies typically 
employed in computer systems. Various VCO controllers 
derive descriptive text messages from the labeling 
facilities offered here, and then send them to the VCO 
terminal output port. 

• Event Labeler Mechanism provides functions to 
return string labels for various VCO events 
of all types. In addition to returning text 
labels for the standard VCO notification 
events, this controller supports labeling for 
the generalized class of VCO events that 
includes all of the enumerated states, 
constants, modes, and string tokens 
representations of the arguments used by the 
Media Control Object Device Control 
Mechanism. The command encoder /decoder 
mechanisms also rely on the services offered 
by this component. 
• Object Component Labeling Mechanism provides 
labels for VCO objects and constructs that 
are used to report the current location of 
execution, or processing, in terms of the 
names of actual VCO components invoked. 
Contains the names of the VCO classes, 
controllers, an mechanisms that are used to 
formulate precise reports for debugging, 
diagnostics, and general troubleshooting of 
VCO components . 
• Event and Object String Label Database 

contains tables of text tokens and string 
messages accessed by the event/object 
component labeler mechanisms. 
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Device/Protocol Controllers 

The Device/Protocol Controllers for the VL and PDI 
layers, as shown in FIG. 3, represent the contribution of 
each layer in producing the virtualized multimedia 
connection services logically defined in the 
corresponding VDI controller (that occupies the same 
physical location on the drawing relative to the group of 
Device/Protocol Controllers) . This group of VL 
controllers serves to support the implementation of the 
device-independent procedures and operations supported, 
at their highest level, by the corresponding controllers 
in the VDI. As the VL controllers are specifically 
Visualization Layer components, they serve to support 
the implementation of VDI controllers by providing any 
necessary coercion of data format, command syntax, or 
interface method, from a vendor-specific modality, to 
that defined for the VDI. In many cases, the VL supplies 
a standardized function supporting a like standardized 
VDI function, but the embodiment of that in the VL is 
fully intended to be implementation-dependent. 

• Software Component Load/ Initialize provides 
implementation-dependent mechanism to load 
and initialize all supporting software 
modules, libraries, and device drivers 
necessary to vco operations. Called by vco 
constructor, the VCO construction fails if 
all necessary components are not present or 
fail to load. No devices of any sort are 
initialized or accessed explicitly here, 
except to determine if they are installed. 

• Software Component Unload/ Shutdown provides 
implementation-dependent mechanism to unload 
all supporting software modules, libraries, 
and devices drivers. Does not shut down 
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devices directly , but does free all resources 
associated with VCO. 

Configuration Information Access provides any 
necessary mapping of configuration 
information from/to the format used by the 
backing store method. Typically reads 
from/writes to a string-based initialization 
file and translates the string token format 
to that used by the VCO configuration 
parameters . 

Data Exchange Syntax Mapping provides mapping 
of file and record formats to that utilized 
by the connectivity protocol stack to that 
used by the host operating system. Examples 
include conversion of buffers and files 
to/ from packet formats. 

Call Event Mapping provides translation of 
vendor-specif ic connectivity protocol stack 
representation of call and line states to 
those used by the VCO call controller. 
System Information Mapping provides 
translation of various vendor-specific 
representations of system information to/ from 
those used by the VCO, and enables 
translation of Media Control Object Device 
Control operations to H.221 device modes. 
Specific translation examples include call 
destinations , and media device states. 
Capability Mapping provides translation of 
local and remote station H.221 capabilities 
emanating from the network protocol stack to 
those used by the VCO. Includes mapping of 
H.221 capabilities to Media Control Object 
capabilities. 
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system Exception Mapping provides translation 
of various fatal errors from vendor-specific 
components to standardized VCO exceptions. 
Media Device Driver Access Mapping provides 
translation of Media Control Object Device 
Control operations to Media Control Interface 
string commands that are presented to the 
Media Access Control layer. 
• Protocol Mode Mapping provides mapping of 
H.221 bit-rate allocation signal (BAS code) 
indications used by the connectivity protocol 
stack (or emulated) to the device- independent 
representation used by the VCO. 

Physical Device Interface 

15 Contains all procedures and data structures used 

to interface device drivers and operating system 
resources directly. All implementations of functions are 
assumed to be device-dependent, and it is the principle 
objective of this layer to locate some form of physical, 
20 or emulated support to realize those operations logically 
defined in the VDI . if the PDI cannot provide, or even 
emulate, a service specified by the VDI, then it must 
return a result code indicating that it is not capable of 
doing so. 



25 Device/Protocol Controllers 

The Device/Protocol Controllers for the PDI layer 
represent the contribution of this layer in providing the 
physical interface component of the virtualized 
multimedia connection services logically defined in the 
30 corresponding VDI controller. This group of PDI 

controllers serves as the physical implementation of the 
corresponding operations managed by controllers in the 
VL. As the PDI controllers are specifically physical 



WO 98/09213 




PCT/US97/15018 



- 59 - 

layer components, they support the implementation of VDI 
controllers by directly accessing device drivers and 
vendor-specific library software components provided by 
third party OEMs; in the most efficient designs, the PDI 
5 may be implemented as an actual device driver, directly 
controlling hardware. 

• OEM Support Libraries and Drivers provide 
specialized "functions, such as image 
processing, digital signal processing, data 

io port interface, and system diagnostics, that 

are vendor-specific and usually hardware- 
specific. 

« configuration Information Backing Store is 

the physical device that stores the vco 
15 configuration information. Usually a file on 

disk and/or some form of non- volatile memory 
device. 

• connectivity Protocol Stack is the actual 
interface to the network, and includes all 

20 associated hardware and software components. 

The network service is presented to the VCO 
session components and transducers at the 
level of the OSI Transport Layer, whose 
responsibility it is to ensure reliable 

25 transfer of messages between end users. The 

Network and Data Link layers must be 
available, in some form, below the Transport 
Layer, and a physical or emulated network 
interface unit must be present and 

30 detectable. 

• Media Access Control provides physical device 
control mechanisms for input and output 
transducer devices in the system. This driver 
complement is used directly to implement the 

35 pdi ' s defined set of device control interface 
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functions used directly by the VDI, as well 
as by the Media Control Object Device Control 
Mechanism. 

• Device Capability List resides in the PDI as 
the master list of the all of the VCO 
capabilities. It is stored as an array of 
device-independent capability constants that 
reflect the range of H.320 (H.221) capability 
BAS codes. 

• Device Mode List resides in the PDI as the 

master list of the all of all possible device 
modes for any H.320 compliant station. It is 
stored as an array of device-independent 
device mode constants that reflect the range 
15 of H.320 (H.221) mode command BAS codes. 

• Media control Objects (MCO) are constructed 
and maintained by the PDI, and presented to 
the VDI, as a method to control all signals 
to and from remote stations and transducers 

20 under VCO administration. The PDI interacts 

directly to support the device-dependent 
implementations that underlie these device- 
independent representations of 
audiovisual/data signals and devices as 

2S discreet system objects, each possessing a 

structured set of properties and wedl-def ined 
operations. 

VCO SOFTWARE ARCHITECTURE 
System Dynamics 

It is useful to consider the VCO as a mechanical 
device, much like a spring-driven mechanical clock 
movement. Each VCO is a self-contained machine of 
interlocking parts, with a system timer interrupt 
advancing its works by the increment and released in 
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balanced measures that bring stability and smoothness of 
operation to the system's "top" end. The VCO's analogous 
"unwinding" takes place with the literal precision of a 
clock's escapement mechanism, in that the system timer 
5 serves as the regulatory entity releasing a steady pulse 
of queue-stored activities from the device control sub- 
systems, to a client application. A Virtualized 
Multimedia Connection System presents not only an 
idealized control mechanism to applications, but also 

io idealizes the rate and content of the system's responses 
to these controls, without ever losing a system event, 
state change, mode change, exception or interrupt 
request. The overall VCO design is consistent with that 
of multi-threaded, queue-based device driver designs that 

is account for a significant portion of the dramatic gains 
in reliability and performance seen in the use of 32-bit, 
multi-tasking operating systems such as IBM's Operating 
System/2 (see H.M. Deitel, M.S. Kogan, The Design of 
OS/2, Reading, Massachuetts , Addison-Wesley , 1992). 

20 Notes On Drawing 

FIG. 4 depicts an a detailed diagram of the major 
components and control flows of the Virtual Connection 
Object software architecture. The Device/Protocol 
Controllers shown are the same as those shown in FIG. 3, 

25 but the purpose in this drawing is to illustrate the 
direction of control flow through them, rather than to 
describe what they are. This discussion will examine the 
VCO in terms of its specific software mechanisms. To 
clearly show the functionality of individual VCO 

30 components in the two-dimensional drawing, it is 

necessary to alter their exact locations in the layering 
model from a perfect vertical orientation, to one more 
suited to revealing component interactive pathways. 
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Summary of vco software Architecture 

The software architecture of the VCO is can be 
described best in terms of two major functions: (a) 
controlling the multimedia connectivity sub-system it 
encapsulates, and (b) responding to events emanating from 
it. What ensues is a brief overview of outstanding 
features that characterize the dynamics of the VCO 
software model. 

• The Software Control Interface (SCI) contains 
public member functions that enable a client 
application to access a consistent and 
logically-defined multimedia connectivity 
service to create a live audiovisual 
connections to a remote station. Calls to 
these members invoke the various 
Device/Protocol Controller services in the 
various VCO layers until some physical 
operation is eventually performed, the result 
of which is translated to logical, 
standardized result prior to being returned 
to the caller. 

• Each VCO contains a general repository for 
all system information that is continuously 
updated to reflect the current states of all 
controllers and devices. 

• Every vco has standard input and output 
terminal ports that function much like the 
standard input and output devices in 
operating system shell console devices. All 
text message sent to the VCO terminal output 
port are written to a list of terminal I/O 
devices maintained by a Terminal Stream 
Controller. This controller also accepts text 
commands written to the terminal input port 
and decodes them, translating them to SCI 
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calls* An infinite FIFO event queue accepts 
the addition of events asynchronously , in 
real-time , by device control software, and by 
software components in the VCO that generate 
their own particular events/ 

An Event Dispatcher runs synchronous with the 
operating system scheduler (does not preempt 
the regularly scheduled time slices) to 
remove events from the queue at a constant, 
periodic interval and disperse them to a 
Notification Controller. 

The Notification Controller examines the 
dispatched event, dispensing notification 
information about the event via Notifier 
Objects that send the indication, and all 
associated information, to an event processor 
in the VCO (if the event is from a device), 
or to a client application object, depending 
on the Notifier Object's configured 
destination object. 

The VCO Device Event Processor invokes 
procedures to respond appropriately to events 
emanating from the device control sub-system, 
so as to maintain a connectivity session with 
the connected remote station. Call control, 
capability exchange, and various protocol 
operations are driven by the event processor, 
as is the issuance of text messages, 
describing all system activities, to the 
terminal output port. Most network events 
that require attention from the application 
in similar multimedia connection systems do 
not require such attention by VCO Clients; 
specific intelligences in the Device Event 
Processor component better direct them to 
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invocation of specialized internal procedures 
more suitable to such tasks, by their very 
designs — feedback loops often found in the 
application layer, reside in the VCO proper, 
alleviating the application developer from 
implementing sensitive protocol-specific 
modules. 

Ubiquitous throughout the VCO's controllers 
are reporting mechanisms that formulate 
detailed text messages describing the current 
state, mode, process, subroutine, class name, 
or event that is currently most relevant, and 
sending this string to the terminal output 
port. An Event and Object Labeler working in 
conjunction with a string database, has 
features that can assign text names and 
terms, in addition to maintaining a text- 
token definition of the VCO text command set. 
VCOs can link together across a connection to 
control or monitor the activities of the 
other station. This concept, referred to as 
attachment, utilizes a bi-directional text 
message stream to enable interconnected VCOs 
to share commands and events. Depending on 
the negotiated configurations of the 
-attached" VCOs, calls to member functions in 
the SCI of one, are encoded into text 
commands by the Command Message Encoder, and 
transmitted to the other station. Upon 
receipt, the Command Message Decoder 
translates the text commands back to SCI 
calls. Correspondingly, events queued at one 
station, as well as results of operations, 
are encoded by the Event Message Encoder, and 
transmitted to the other station. Upon 
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receipt, the Event Message Decoder translates 
the text event messages back to events and 
adds them to the event queue, where they are 
dispatched along with a station identifier. 

5 software Control Interface 

The Software Control Interface (SCI) consists of 
the VCO's public member functions and protected data that 
allow client applications to control the VCO. Any request 
for service using the SCI must pass a number rigorous 

10 examinations designed to reject any possibility of 

damaging the encapsulated sub-system. A client attempt to 
access a VCO member function results in an immediate set 
of verifications to determine if VCO is available for 
use, and if so, whether the context of the request is 

is valid. For example, most operations require that the 
device control sub-system first be fully initialized. 
Arguments are checked for validity, and a text message 
describing the request is sent to the VCO terminal output 
port for tracing and monitoring purposes. If all 

20 conditions have been met, execution continues to the next 
level; progressing typically to a further request to the 
PDI. Rejected requests are turned away abruptly, but the 
client is compensated for his diligence, with a fair 
accounting of the dismissal; every operation returns a 

25 concise result code. 

Member Functions 

Member functions to invoke the services of the VCO 
are partitioned into several distinct categories. The 
members and their arguments are highly structured and 
30 flexible in the variety of ways they may be utilized. 
They are easily mapped to a text-token command set. All 
of the members of this interface are available from one 
constructed VCO, and each optimized to best support the 
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likely use of it, rather than providing similar access 
methods for all command permutations equally. The 
pathways through the VCO layers and components are unique 
for each functional group, and are summarized briefly: 

Event Notification Control Members make calls 
to the Notifier Object List Manager to 
create, delete, and configure, and trigger 
Notifier Objects in the Linked Notifier 
Object List, calls to trigger notification 
invoke the Notification Triggering Mechanism 
directly. 

• Terminal Service Control Members make calls 
to the Terminal Stream I/O Device Controller 
to add and remote devices from the Linked 
Terminal Stream I/O Device List. Calls to 
send text messages to the terminal output 
port are made through this object, as are 
calls to send text command message to the 
terminal input port for decoding and 
execution . 

• Configuration/ System setup Control Members 

make calls to the PDI to store and retrieve 
configuration information from some physical 
backing store device. 

Network Session Control Members make calls to 
the PDI to initialize and shutdown the 
encapsulated multimedia connectivity sub- 
system, as well as to initiate and terminate 
sessions with a remote station. 

• Audiovisual/Data Signal Switching Control 
Members make calls to the PDI to manipulate 
audio, video, image, and data objects that 
comprise the Media Control Object Device 
Control System of the VCO. 



WO 98/09213 



PCT7US97/150I8 



• Binary Data Object Exchange Control Members 

make calls to the PDI to transfer binary data 
objects and data buffers to and from the 
remote station. 
5 • system Information Store/Retrieve Control 

Members make calls that access the VCO system 
information repository in a structured 
manner; a manner which does not allow for any 
direct modification of VCO data structures, 
10 • Protocol Management control Members make 

calls to the PDI to directly set H.230 device 
modes, send capabilities to the remote 
station , and perform other protocol related 
tasks . 

15 Terminal service 

The VCO terminal service has two main pathways: 
into the VCO through the terminal input port, and out of 
the VCO through the terminal output port. Alternately, 
when the terminal ports are considered as standard input 
20 and standard output devices for the VCO, it is sensible 
to view the two modalities as a stream "to the terminal" 
and "from the terminal". 

• output Streams to VCO Terminal originate from 
the VCO itself, or from client applications, 

25 Messages "to the terminal" are directed to 

the terminal output port and dispersed, via 
write operations, to output devices (attached 
to the terminal output port). Summary, 'To 
terminal" is synonymous with " to text output 

30 devices," 

• Input Streams from VCO Terminal originate 
from outside the VCO, typically from a dumb 
terminal or client application wishing to 
control it with text commands, SCI calls 
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sending text messages as if "from the 
terminal" are directed to the terminal input 
port and interpreted as input text command 
messages, as if input from a keyboard. 
Summarily, ■ From terminal" is synonymous with 
"from the standard text input device." 
Terminal stream l/o Device Controller 
maintains a linked object list of output 
device objects to which the text message sent 
to the terminal output port are written. All 
text messages sent to the terminal output 
port are written to every device cataloged by 
the linked object list. Output devices 
include system files, character devices, and 
Notifier Objects created for the transmission 
of text message to objects. 

System Information Handling 

System information is fully protected from direct 
external access the vco, though all internal components 
can access it directly. Clients must us specific member 
functions to get a copy of the data, and use other 
members to affect changes to it through structured 
operations. Internally, all system parameters are fully 
accessible to all components derived from the VDI. 

• Configuration Parameters store the current 
copy of vco configuration and system setup 
information that is read from backing store 
at vco construction time. Contains 
information about the network service 
available, and all system defaults. The 
parameters can be modified and written back 
to backing store at any time. 

• Device Parameters store all settings and 
parameters related to the 
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audio/ video/ image/data devices installed in 
the sub-system , and retain handles to the 
current source, destination, input, and 
output signals affected by the Media Control 
Object Device Mechanism. 

Call Parameters store all of the current call 
and line states, including those for 
multipoint calls. Maintains records about 
other stations in the conference. 
Protocol Parameters store all current 
transmit and receive modes for all the 
various data types. 

Control Prameters stores all information 
related to maintaining the remote station 
control mechanism for any attached station. 
Monitor Parameters store all information 
related to maintaining the monitoring access 
for any attached station. 

Notification Mechanism 

20 The VCO notification mechanism conveys an 

indication that a particular event has occurred by 
activating, or "triggering" , a notification entity 
referred to as a Notifier. Maintained in a list internal 
to the VCO, Notifier Objects are created specifically to 

25 call a member function of some appropriately enhanced 

class object, somewhere in the system (within or without 
the address space of the VCO) when triggered. Upon the 
VCO event dispatcher's presentation of an event to the 
Notification Controller, Notifier Objects in the list are 

30 systematically examined, and potentially triggered, 

according to a specialized modality of governance that 
considers the relationship of the outstanding event type 
(among other parameters) to the triggering profile of the 
Notifier Object itself. 
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Notifier Objects (NO) 

These objects comprise the basic indication unit 
of the VCO notification mechanism. Each NO is an instance 
of a class object that may be created by a VCO client, or 
5 the VCO itself, and configured to -trigger- in response 
to the occurrence of any one of a set of VCO events. Each 
NO is associated with a specified Notification Receiver 
Object (NRO) to which the trigger response is directed. 
When an NO triggers, it makes a function call to the 
10 associated NRO member function assigned to the task of 
handling notifications. Passed to the NRO is an event 
identifier, and a number of gualifying arguments that 
describe the context of the event's occurrence. There are 
two mutually exclusive modalities for any NO; they can be 
is configured to respond to any event, or configured to 
respond only to events emanating from VCO-encapsulated 
devices. 



Notifier Management 

This task is handled by the Notifier Object list 
20 handler. This component adds to, removes from, and 
maintains the integrity of the Notifier list. It also 
provides members for configuring Notifier Objects with 
new trigger response profiles, as well as to allow them 
to be enabled, disabled, and examined for statistical 
25 information. In the VCO, the notification mechanism is 
supported by a component that manages the list of all 
active Notifier Objects, and a triggering mechanism that 
determines as to whether or not an individual Notifier 
should trigger, based upon the occurrence of an event to 
30 which it is configured to respond. 

Triggering Mechanism for Notifier Objects 

This mechanism conditionally determines as to 
whether or not a Notifier Object should trigger, based 
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upon a specific algorithm. Notifier Objects can be 
configured to respond to events that emanate from the 
device only, so as to direct their trigger response to 
the VCO Device Event Processor. Through this method, the 
5 VCO uses Notifier Objects internally to create a direct 
pathway for device events (added to the VCO queue by the 
device) , to be processed in the VCO Device Event 
Processor exclusively. This distinction serves to prevent 
an infinite loop that would result if the VCO processes 

10 an event from a device, and then reissues (requeues it) 
it so that client applications can be subsequently 
notified of the same event — the same event would be 
dispatched back to the event processor again and again if * 
reinterpreted as another occurrence of the same device 

is event. Thus a distinction must be made between the 

original device event and a processed derivative of that 
same event intended for dispatch to the client 
application. Notifier Objects configured to trigger on 
events directly from devices will only trigger on events 

20 directly from devices. When the event processor reissues 
the event from the device, it marks it to indicate it is 
not directly from a device, and it can no longer trigger 
the Notifier that would send it to the Device Event 
Processor. 

25 Notification to Clients 

VCO Client applications may request notification 
of a combination of VCO events by creating a Notifier 
Object and configuring it to trigger when any single 
event in the combination actually occurs. Once created, 
30 the Notifier Object conveys event notification to an 

application object set to that purpose. The object that 
receives notification is referred to as a Notification 
Receiver Object (NRO) . 
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Notification Receiver Objects (NRO) receive 
function calls from an entity in the VCO that 
is created specifically to direct 
notification of the occurrence of an event to 
them. A class object can serve as an NRO if 
it contains a special Notification Receiver 
Member and an attendant thunk. The thunk is a 
globally accessible function that is created 
to receive notification from the VCO and 
redirect that notification to the NRO's 
Notification Receiver Member. In this way, a 
VCO can deliver a notification message to a 
class object which can then directly access 
other class members and member data that 
would not be available if the notification 
was to a non-member function i.e. had to 
access class members with a special class 
pointer . 

Notifier Triggering Profiles refer to the set 
of events to which the Notifier Object is 
configured to respond. Notifier Objects are 
"triggered" to notify their associated NRO 
when one of these configured events occurs. 

Event— Handling Mechanism 

The event handling mechanism consists of three 
concurrent, but distinctly separate processes. From the 
perspective of any single event, these processes occur in 
a serial fashion. First, events are added to the trail of 
the VCO event queue by various VCO components. Next, a 
30 concurrently executing event dispatching process 

periodically removes an event from the queue. Finally, 
the event dispatcher sends the removed event to the 
Notification Controller where it triggers Notifier 
Objects configured to respond to events of this 
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particular type. If the event is a device event, and the 
Notifier is configured to respond to device events, then 
its Notification Receiver Object receives notification 
that the event has occurred. If the event removed by the 
5 dispatcher is some derived event, it may trigger 
notifications to client application, or any other 
Notification Receiver Objects targeted by a Notifier 
responding to that event; 

Device Events 

10 These events are generated directly by a device in 

the encapsulated sub-system; a situation that potentially 
requires some kind of immediate responsive action. They 
are the primary responses from VCO devices and emanate 
from network and media control driver software 

l 5 components . 

Derived Events 

These events are generated by a VCO software 
component, and are derived from an action or logical 
state, not directly emanating from a device. They are the 
20 secondary responses from the VCO itself, often resulting 
from the processing of device events. 

Event Processing 

The task of event processing includes the handling 
of both Device Events and Derived Events. Device events 

25 can only trigger Notifier Objects configured to respond 
to device events, thereby enabling a particular Notifier 
Object to function as a dedicated device event notifier. 
Events entering the Device Event Processor are typically 
line state changes, device mode changes, and indications 

30 from the remote station. These events drive protocol and 
session management routines during processing, which in 
turn generates derived events such as the call state 
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changes and Media Control Object Device Control parameter 
changes. These derived events are queued for subsequent 
dispatching to client applications; these secondary 
occurrences are treated differently from primary events 
s in that they will not be handled by the Device Event 
Processor. 

Event Dispatching 

Dispatching of events occurs periodically at a 
programmed rate that may be adjusted dynamically at run- 
10 time. Typically, dispatching five events per second is 
sufficient to present the client application with a 
manageable stream of events. The event dispatcher is 
driven by a system timer interrupt, if the queue is 
available for mutually exclusive access, it is checked to 
determine if there are events in it. If there is at least 
one event in the queue, one event is removed in a 
critical section, and the gueue is released to the 
system. If mutually exclusive access is not immediately 
available, or there are no events in the queue, the 
20 dispatcher yields. Otherwise, the removed event is next 
presented to the Notification Controller where any 
Notifier Objects in its list, sensitive to the event, are 
triggered so as to disperse the event throughout the 
system 

25 Event Queuing 

Queuing of events occurs sporadically, when an 
event is generated by a VCO-encapsulated software or 
hardware component. Frequently occurring during hardware 
interrupt cycles, queuing is carefully optimized to 
30 require very few cycles and little resource allocations. 
A short blocking operation may be necessary during 
dispatching to gain mutually exclusive access to it. The 
event is added and the queue released back to the system. 



WO 98/09213 




PCT/US97/15018 



- 75 - 

If the attempt to add an event to the queue fails, a 
fatal error (VCO Exception) occurs and the VCO is 
permanently disabled. 

Exception Handling Matters Mechanism 

5 The VCO exception handling mechanism is not shown 

in FIG. 4. Exceptions in the VCO are conditions that are 
deemed fatal errors from which the system cannot recover 
vithout risking a system crash. The underlying design 
principle to VCO exception handling is that system 

xo crashes result most often from continued use of a 

destabilized system component, from attempts to recover 
from destabilized conditions, and from the failure of a 
destabilized system to acknowledge its "time-bomb" 
status. In accordance with an overriding concern for 

is system reliability, VCO exceptions generate reports, and 
a subsequent disabling of the VCO. Neither the VCO, nor 
its concomitant support software, is accessed until the 
VCO is destructed. Once disabled, all calls to the SCI 
return immediately with a result code indicating that the 

20 VCO has been disabled. For continuous use applications, 
the risk of system crash is rendered unlikely, and the 
system witYi one destabilized sub-system likely remains of 
sufficient health to invoke a resident backup system. 

Fatal errors occurring internally to the VCO 

25 generate an internal assertion failure that invoke a 

recovery routine that proceeds to execute a reverse stack 
trace. The trace searches for markers pushed onto the VCO 
stack during calls to a special member function called 
upon entry into the VCO. Every VCO entry point is guarded 

30 by a call to a function that returns a result code 

indicating whether or not the VCO is enabled or disabled. 
Upon locating the address of the instruction pointer. (on 
the stack) at the execution point of this status call, a 
result code indicating that the VCO is disabled is pushed 
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onto the stack, along with the address of the entry 
point. A return instruction is executed to bring the 
calling thread back to its original point of execution 
just prior to calling the VCO status member (which will 
5 indicate that the VCO is "unavailable" when the status 
call is re-executed) , and to the impression that it has 
been turned back at the door due to a preexisting 
disabled state. The calling thread is without cognizance 
of the fatal error it unwittingly generated by its 

10 venture inside the VCO, and finds the VCO is simply 

unavailable for continued use. This technique of shutting 
down the damaged VCO, accompanied by transparent error 
handling (from the perspective of invoking applications) , 
maintains system integrity until the host system can risk 

15 a recovery operation. 

Exception Handler Modalities 

A variety of VCO exception handling modes can be 
invoked incrementally by specifying any combination of 
the following modality flags. These modalities are 
20 additive, and affect the way in which reporting of the 
exception is handled. 

• Debug modality flag, if set, specifies that 
detailed debugging information (in a message 
box) will be displayed at the time of 

25 exception. This mode is intended for use 

during system development where proprietary 
information will be displayed. 

• User modality flag, if set, specifies that 
general "user" information (in a message box) 
will be displayed at the time of exception. 
This mode is intended for use in the field 
after the product is released. 

• Term modality flag, if set, specifies that 
exception information will be sent to the VCO 
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terminal output port for display on terminal 
output devices. 

• Notify modality flag, if set, specifies that 
the exception will generate an exception 

s event and trigger Notifier Objects prior to 

disabling of VCO. 

• Abort modality flag, if set, specifies that 
the exception will abort all VCO operations, 
after reporting the exception, and disable 

10 the VCO. 



Event and Object Labeling Mechanism 

This mechanism provides function calls that 
convert indexes to strings. It relies on a collection of 
string tables, whose string element positions reflect the 
15 value of the indexes. The string tables can be loaded 

from resource files that contain text in the appropriate 
language . 

Labeling of Events, Enumerated Values and Result Codes 

Retrieving a text label to describe a VCO event is 
20 accomplished by presenting a VCO event identifier, result 
code, or standard enumerated constant to the appropriate 
member function. A pointer to a static copy of a null 
terminated label is returned, and is typically used to 
formulate messages for terminal output, and by 
25 applications to display states, modes, and operations 
taking place in the VCO. 

Labeling Objects 

Retrieving a text label for a VCO software object 
is accomplished by presenting a pointer to the object to 
30 a member function. A pointer to a static copy of a null 
terminated label is returned, and is typically used to 
formulate messages for debugger and trace window output. 
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Used specifically for debugging, diagnostics, and 
troubleshooting. 

Event and Object string Label Database 

A memory resident database in the VCO contains 
tables of string records for all of the VCO enumerated 
constants, and the VCO command set. Reference databases 
containing object pointers and labels are created at VCO 
construction time. 



15 



20 



10 Media Control Object Device Control Mechanism 

Designed to facilitate the manipulation of signals 
as distinct objects, this device control method is 
intended for full implementation as a graphical desktop 
media control system, supporting a drag and drop signal 
switching model. Each object, representing a specific 
signal type, has a standardized set of properties, and 
well-defined modes of interaction. The physical structure 
of the Media Control Object Device Control Mechanism 
represents each signal as a software class object, and 
all signals currently available in the system as a linked 
list of such objects in the VCO DEVICEPARAM structure. 
Media Control Objects are created and deleted as signals 
become available, or unavailable, depending on connection 
state and device availability. 

VCO signals are identified according to their type 
and direction. The possible types of signals include 
audio, video, image, and binary data. The possible 
directions include input from the remote station, output 
to the remote station, input from a local transducer, and 
output to a local transducer. Member data in each Media 
Control Object describe the current states and modes 
related to the signal. Member data in each Media Control 
Object describe the current states and modes related to 
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the signal, and member functions invoke physical 
operations in their host devices. 

It is possible to determine if a given Media 
Control Object is capable of specific operation by 
5 setting the query flag on the SCI member function to 
control them • In this manner, the client can test an 
operation without invoking it. A special function to 
return the capabilities of a setting is also available, 
and a list of settings constants (or parameters for the 

io setting) is returned. For H.221 capabilities, related to 
the multimedia interconnection protocol, the VCO 
parameter block maintains an updated listing. There is a 
very close logical mapping between H.221 capabilities and 
Media Control Object capabilities — no H.221 video mode 

15 means that there is no motion-video available — and it 
is likely that the very existence of a Media Control 
Object indicates that most of the operations for that 
signal type are supported to some degree. It is often 
sufficient to let a client attempt to set the mode, and 

20 report that the system is incapable, than to constantly 
monitor and maintain a local capability listing. 

Device/Protocol Controllers 

The divers Device/Protocol Controllers, discussed 
in the overview section, each have emulation components, 

25 shown in FIG. 4, that reside in either/both the VL and 
the PDI. The objective in any VCO emulation mode is to 
enable to the VDI to operate fully, without the ability 
of it, or any client applications, to differentiate 
between operation with actual device support, or 

30 emulation of it. There is an emulation mode flag in the 
system information that determines the operating mode. 
Any operations supported in the VL or the PDI must check 
this flag during every invocation of service, and either 
access a physical device, or provide a set of results 
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indistinguishable from having done so. No support for 
emulation of operations exists in the VDI - it makes no 
direct references to low-level device services except 
through the PDI. 

s Remote Station Attachment Mechanism 

Attachment of a remote station to the local 
station enables the local station to monitor its event 
stream and control its operations. The basic mechanism of 
attachment has been discussed in general, however the 
io specifics of this interaction deserve more attention 
Essentially, an attachment mechanism sufficient to 
monitor a remote station requires a cross-linking of the 
output of one station's event encoder to the other 
station's event decoder. To establish control of a remote 
is station, there must, in addition, be a cross-linking of 
the output of one station's command encoder to the other 
station's command decoder. There are a number of 
operational considerations that become the subject of 
negotiation between the stations, once attachment is 
20 accomplished. 

Monitor Context: 

Monitoring context refers to the station that is 
the source of the current event stream emanating from the 
local VCO's dispatcher. Any combination of the monitoring 

25 modes can be in effect once attached. A VCO that is not 
attached to a remote station can only monitor local 
events. The remote station must grant permission to be 
monitored by the local station by indicating so in its 
monitor parameters, vco monitoring modes are described as 

30 follows: 

• Local monitoring mode affects the target VCO 
to dispatch and process events local to it. 
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• Remote monitoring mode affects the target VCO 
to dispatch and process events emanating from 
the remote station to which it is currently 
attached . 

5 • Array monitoring mode affects the target VCO 

to dispatch and process events from a 
specified array of remote stations. 

Control Context 

Control context refer to the station that is 

10 controlled by calls to local VCO SCI member functions. 

The remote station must grant permission to be controlled 
by the local station by indicating so in its control 
parameters. VCO control modes / from the perspective of 
the local station, and when set in the physical local 

15 station VCO, are described as follows: 

• Master control mode enables the local station 
to control a remote station to which it is 
currently attached. 

• 8 lave control mode enables the local station 
20 to be controlled by a remote station to which 

it is currently attached. 

• Peer control mode enables both the local and 
remote stations (attached to each other) to 
control themselves, but not each other. This 

25 is the standard operating mode for most 

interconnections between stations . 



CLIENT SOFTWARE ARCHITECTURE 

FIG. 5 depicts a VCO client application; arrows 
highlight the flow of function calls through its various 
30 components. The diagram shows a full implementation of a 
VCO client application that best describes the VCO Client 
application concept. All of the components shown are not 
necessary to establish a minimally-functional multimedia 
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connectivity session with a remote station, but are 
needed to make full use of the entire VCO feature 
complement. The client application specification, unlike 
that for the VCO itself, is represented in a generalized 
fashion, and strict compliance is not necessary to 
achieve the benefits touted by the VMCS; a broad range of 
effective application designs may be derived from this 
prototypical VCO Client application model illustrated. 

summary of Client Software Architecture 

A client application selects a class library 
supporting an implementation of class VCO. Constructing 
class VCO, it makes calls to the Software Control 
Interface for the newly invoked VCO to establish a 
connectivity session with a remote host. The client has a 
number of components that it uses to manage this session: 
• The Device-independent Connectivity 

Application Shell provides the user- inter face 
and basic task management for the client 
application. This component displays session 
status information, and initiates the 
milestones of its inception and termination. 
This component is the logical control 
mechanism for all vco operations, if it is to 
construct a VCO directly, it must be created 
with the same object-oriented language as the 
VCO itself. While it is preferred that the 
client is a GUI application to best present 
the VCO control system to the user, it can be 
as simple as a daemon running in background, 
that processes string commands from a data 
stream directed to it. 
• A number of Notification Receiver Objects 
receive notifications from the VCO that 
various VCO events have occurred. Client 
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applications typically create a Notifier 
Object to receive text streams from the VCO 
terminal output port. At least one other 
Notifier Object should be created to receive 
indication of the three major classes of new 
local station modes (new H.221 transmit 
modes) , new remote station modes (new H.221 
receive modes) , and new call state changes 
(new call and line states) — one Notifier 
Object can be configured to respond to all 
three of these event types. 
Event and Text Processing Components are 
specifically designed to analyze and/or 
respond to text and event information 
emanating from the VCO. Text processing of 
the terminal output stream can take the form 
of graphical display in a trace window that 
has the facility to enable its viewer to move 
forward and backward through the output 
messages, in order to view the progress of 
the session. Trace information could also be 
saved to a log file to permit later analysis 
of session activity. Finally, trace output 
can be analyzed by a debugger, or H.320 
protocol analyzer. New remote station modes 
are usually routed to the Station Profile 
Controller for processing and interpretation. 
The Station Profile Controller examines new 
modes set by the remote station, and using a 
Station Profiler, compares them to a 
database, to determine the remote station's 
manufacturer or type. Once identified, the 
remote station's profile is elicited from 
that same database, and its non-standard 
feature set made available to the 
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application. Non-standard features include 
advanced camera control operations, 
proprietary VCO features, data exchange 
protocols, and application sharing features. 
Non-standard capabilities are also examined 
to determine the level of functionality, of 
which the remote station is capable. The Non 
standard H.221 Mode Mapper provides a 
virtual ized representation of the remote- 
station's available special features, and 
presents them to the application shell in a 
manner conducive to their mapping to local 
station physical controls. 

Application Notification 

In the general sense, a stream of events flows 
from the VCO to the client. Ongoing notification of the 
application, by the VCO, in the form of multiple 
concurrent event streams delivered to application class 
objects, changes the context of the VCO from a sub-system 
invoked by the client, that returns values in response to 
commands, to an adjunct connectivity operating system; an 
operating system running in parallel with the primary 
operating system, actively communicating with its client 
application processes through an interrupt- like 
mechanism, and similarly operating completely 
independently to specifically manage system multimedia 
connectivity resources. 

Notifications from the VCO, to its client 
applications, take place using a mechanism designed to 
provide structured entry points that function much like 
interrupt service routines. From the perspective of the 
client, the design eliminates the risk of interfering 
with the delicate timing of the underlying multimedia 
connectivity sub-system, and does not confound normal 



WO 98/09213 



PCT/US97/15018 



- 85 - 

time slice allocations by the operating system scheduler. 
At the level of the application, notifications are 
discreet entities that are independent of any operating 
system or GUI event processing/ queuing schemes, and 
5 resultantly more time-responsive; so much more responsive 
than adding events added to the application event queue, 
that notifications can preempt drawing operations by the 
GUI, but without inordinately starving the GUI of its 
time slices. The notification is usually implemented to 

10 run on a separate thread, concurrent with those drawing 
on the display, and thus connectivity events can be 
processed concurrent with drawing, rather than subsequent 
to a GUI operation in progress. The VCO Client 
notification system permits the design of high- 

15 performance, multithreaded applications that can process 
and respond to connectivity events with responsiveness 
that (in the context of a user interface) approximates 
real-time. Notification to VCO client applications, 
proceeds with rapidity such as is required for 

20 controlling both local peripheral devices, and the 

peripheral control features of remote stations, while 
concurrently maintaining a responsive graphical desktop 
display. 

Notification Receiver Objects 

25 In the application, any class object can be 

configured to receive calls from a Notifier Object when 
any one of a subset of events occurs. A member function 
in the object is declared for this purpose by the 
creation of a thunk. As previously described, thunks are 

30 created to redirect calls from the Notifier Object in the 
VCO, from a public global non-member function in the 
application (called by the Notifier Object) , to the 
particular class object instance and member function 
intended exclusively for the purpose of notification. The 
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receipt of notifications by the application often results 
in the application's issuance of calls back to the VCC to 
correct, compensate, or respond to the condition. Many 
event handlers in the application function as feedback 
s loops; upon notification, they immediately invoke VCO 
functions in response. Logical assistance by the client 
application is unnecessary once appropriate response 
routines have been setup - the VCO manages the multimedia 
connectivity system automatically. 

10 station Profiling 

The primary objective of the client station 
profiling mechanism is to first identify the remote 
station as one represented in a local database of 
potential remote station types. Once a descriptor for the 
is remote station is found in the database, the client can 
now determine any non-standard device modes (that invoke 
special features) supported by that remote station. 
Further, a list of corresponding non-standard 
capabilities is also stored in the descriptor, such that 
the local station can make a positive predetermination as 
to whether the special feature associated with the remote 
station type, is actually available for use. Nonstandard 
modes supported by the remote station can then be mapped 
to loeai-<:ontrols so that the VCO client becomes capable 
25 of a degree of station control typically only possible by 
interconnection between two stations from the same 
manufacturer - VCO stations can fully understand the 
particular proprietary non-standard features they 
support. The VCO client is capable of an extraordinary 
30 degree of compatibility with an unlimited range of remote 
stations. 



20 
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Station Profile controller 

This software controller contains three components 
that provide the functions necessary to implement: a 
transparent mapping between local station controls, and 
5 remote station non-standard features. Local station 
features, beyond those represented in the VCO control 
mechanism have specific sequences of device modes that 
must be set to activate them. Non-standard modes on the 
remote station work the same way, except the mode 
io sequences are different. The three components of the 

Station Profile Controller enable the client to associate 
any local or remote station non-standard feature (mode 
sequence) with a control on the local station. In short, 
the Station Profile Controller offers a symbolic, device- 
is independent representation of local and remote station 
non-standard features, and beyond that, the ability to 
associate one local with one remote. An example of this 
association is in order: consider a surveillance system 
that maintains two specialized features: 
20 1) It allows an operator to remotely select the 

current camera from a variety of available 
input cameras. 
2) It displays an "X M cursor on the operator 
station video image, pinpointing the exact 
25 center of focus for its currently selected 

camera, and the remote station will move its 
selected camera to correspond to any mouse- 
invoked change in the cursor location on the 
operation display, therein allowing the 
30 remote operator to survey the area with 

simple mouse movements. The remote station 
will continuously reflect the camera's actual 
physical position by rendering a cursor on 
the operator station visual display. There 
35 is no H.320 representation of these 
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35 



operations, beyond support for sharing a 
cursor position; the selection of a remote 
camera is a simple operation, but the second 
feature is one complex, proprietary, and in 
5 need of specialized library support features 

~ the cursor movement mechanism requires a 
complex feedback mechanism to move and 
display the -X M cursor as intended by the 
remote station's programming, when the 
10 operator station connects to this monitor 

station, the operator station determines that 
the remote station is of this particular 
monitoring station type, and locates a 
descriptor in its database that describes it. 
15 The modes to select the camera are 

represented symbolically to the VCO client, 
and mapped to local station controls. The 
sequence of mode-setting operations necessary 
to the selection of the remote station camera 
is invoked by offering the symbolic 
representation of the operation to the 
Station Profile Controller. For the more 
complex cursor-aiming feature, incoming 
cursor position modes are mapped to a 
virtualized definition of cursor movement, 
and passed to functions in a library of 
supporting routines, developed specifically 
to display it as required. Local station 
mouse movements over the video display 
region, on the operator station's bitmapped 
display, are mapped to cursor movements sent 
to the remote station via a similar mechanism 
used for camera selection, it is the VCO's 
notification mechanism that enables the 
concurrent processing of device modes. 
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sending and receiving them to/ from the remote 
station, at the system level of the GUI 
application, without interference from other 
application activities. 

s Station Profiler 

This component is responsible for identifying the 
remote station. Upon connection, it sets sequences of 
modes, and conducts whatever query is necessary to 
determine its manufacturer. To this end, it compares 
10 modes sent back from the remote station to stored 
sequences in the database. 

Non-standard Mode Mapper 

This component maps non-standard local modes, to 
specific features, by assigning mode sequences (and 

is function calls) to an intermediate symbolic 

representation, which is then used in a feature mapping 
table. The same mapping is performed for non-standard 
remote station modes, however the mode sequences are 
preprogrammed, stored in a database descriptor, and 

20 selected according to the identity of the remote station. 

Non-standard Capabilities Mapper 

This component manages the capabilities associated 
with the non-standard modes handled by the non-standard 
mode mapper. It provides a mechanism to determine if non- 
25 standard modes are available on the remote station, as 
well as mechanism to inform the remote station that the 
local station is capable of handling its non-standard 
modes . 

CLIENT VCO ACCESS METHODS 
30 Derived from this design are several methods for 

VCO Clients to access the services of the VCO, so as to 
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make use of the VCO as an independent multimedia 
connectivity operating system that supports client 
sessions. 

Notes on Drawing 

s FIG. 8 depicts the various methods used by VCO 

Clients to access service of a particular VCO. The left 
of the drawing, labeled "REMOTE SYSTEM" , and the right 
labeled "LOCAL SYSTEM" , should not be confused with the 
"REMOTE STATION" or "LOCAL STATION"; access from another 
10 system may be from any computer supporting a text command 
stream to the host system, even from a dumb terminal. If 
the controlling system is a "STATION" (connected across 
the network) , then it must establish a text data stream 
(in-band or out-band) to transceive VCO commands between 
is the two systems. Note that the VCO depicted in the 

"REMOTE SYSTEM" is controlling the local system as its 
master, by employing some command dispatching mechanism 
to connect to the local station, but not necessarily over 

4- W — j i. 



the network. 



20 



Summary of Access Methodologies 

The services of VCOs are utilized by client 
applications that construct them, and subsequently make 
calls to their member functions. Once constructed, the 
VCO lies resident in the host system as an adjunct 
25 multimedia connectivity operating system that can respond 
to requests for service, when accessed in one or more of 
the following ways: 

• Client applications running in the host 

system are able to construct one, or more, 
30 VCOs through the usual Direct Member Access 

method; that is, they call member functions 
in the VCO's Software Control Interface, to 
drive a multimedia connectivity session. 



oca*: <wo_eeoe2iSMj_> 



PCT7US97/15018 



- 91 - 

To provide text command access from a remote 
system, without sending commands across a 
network connection, a VCO/TTY Access Daemon 
can construct a VCO in a host system, and 
then open a command text stream through a 
system communications port. Any remote system 
connecting to that port can send commands, 
and examine the effects of their issuance. 
A VCO terminal session is established upon 
connection to a remote system communications 
port that is being monitored by a VCO 
directly, or monitored by an Access Daemon. 
From the perspective of the remote system, 
the method of creating a terminal session to 
control a VCO, is referred to as Remote 
Command Access. Simply put, VCO commands are 
issued directly from a remote station or dumb 
terminal, to a waiting VCO, or daemon acting 
on its behalf. 

A seamlessly integrated remote VCO control 
solution, referred to as Remote Member 
Access, is an access method that creates, in 
a VCO implementation, a Media Control Object 
that is expressly designed to establish a bi- 
directional text data stream through a 
particular system port. The VCO command/ event 
streams are directed through it, to provide a 
level of control that allows a VCO client, 
invoking VCO members on its own local system, 
to drive a remote VCO transparently. This 
method utilizes the identical components and 
mechanisms as for remote VCO control across a 
connection, except that the command /event 
stream is directed to an out-band 
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communications port, and not the principle 
network connection. 

IMPLEMENTATION 

This section describes the full implementation 
of a VMCS that supports concurrent live audio, live 
video, imaging, and binary data transfer services. The 
VCO portion of the system must be created to support the 
specific configuration of devices installed. Compliant 
client applications will run over any VCO that they 
construct. Any number of VCOs can be created to 
encapsulate divers combinations of devices installed in 
the system. An instance of a VCO (that encapsulates a 
device set) is one of many possible presentations of that 
same device set to an application; a different VCO 
implementation may invoke the same devices in a different 
way, or using different drivers (for example) to present 
an entirely different performance profile. Depending on 
the capabilities of the sub-systems installed, multiple 
VCOs can be instantiated concurrently to provide multiple 
multimedia connectivity sessions at the same time. There 
is no limit to the application of the VMCS paradigm, as 
long as the specified VCO service is provided, through 
some means, to the client application or marked as absent 
in the vco's capabilities listing. 

VMCS HOST SYSTEM REQUIREMENTS 

Implementation of a VMCS is best accomplished in a 
microcomputer host system equipped with peripheral 
devices to process audio and video signals, and a 
connection device to interface with the network. A VMCS 
can be constructed to run over almost any combination of 
the components discussed in the section entitled Host 
System Equipment Requirements below, depending on the 
level of implementation desired; support for concurrent 
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audio, video, image , and data services is hereupon 
described for the disclosure of full VMCS implementation, 
but any partial implementation is possible without 
affecting the basic VMCS design. The VMCS is ideal for 
5 limited usage i.e. only for audio connectivity. 

Furthermore , the bewildering array of devices for audio, 
video, data, imaging, and videoconferencing, that are now 
available, often combine the functionality of two or more 
devices, in which case the perceived differentiation 

10 between them exists only in the software abstraction 
layers that comprise a VCO. For example, an audio and 
video device may be combined on one board, but will 
appear as (map to) a number of discreet functional Media 
Control Object entities, whose hardware support mechanism 

15 is indeterminate, when considered at the level of the VCO 
Client application. 

Host System Equipment Requirements 

Following are the requirements for the host 
computer, adapter cards, peripherals, and system software 
20 components requisite to VMCS implementation, as already 
described. Each item is intended to represent an example 
component; many permutations of features and hardware 
configurations are acceptable for actual deployment, 
though the configuration outlined below is provided in 
2 5 specific terms to enhance the clarity of subsequent 
references. 

• IBM-compatible Personal computer 

A Personal Computer is the preferred host 
system. It should have a Pentium processor 
30 running at l2 0Mhz or faster, contain at least 

sixteen (16) megabytes of random access 
memory, and a minimum of 500 megabytes of 
backing store capacity. 
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32-Bit Multitasking Operating System 

The VMCS host operating system should provide 
protected memory address space for each 
process, support multiple threads, and have a 
preemptive scheduler. 
Graphical User Interface 

A VMCS host operating system user interface 
should be event-driven, and provide a 
windowed graphical "object-desktop" 
environment where each visual component can 
be manipulated by 

drop/drag/cut/paste/properties operations . 
Audio and Video CODEC Devices 
Audiovisual encoding and decoding hardware 
may be integrated with other devices onto one 
or more adapter boards that plug into 
expansion slots in the computer. The CODEC 
devices for this implementation must encode 
audio and video inputs from a microphone and 
camera, respectively, to a multiplexed 
digital signal compliant with the H.221 frame 
structures. Decoding must proceed from this 
H.221 compatible signal to an analog audio 
output, and a VGA video signal for output to 
(for example) a video display terminal. 
Video Display Adapter with overlay Controller 

A high-resolution video graphics adapter must 
be installed so as to work in conjunction 
with a video overlay device. This hardware 
configuration will support the station's 
principle visual graphics information output 
pathway by enabling the simultaneous display 
of bitmapped graphical and motion-video. This 
sub-system must permit motion-video display 
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in a windowed portion of the main screen, a 
region programmatically selected for that 
purpose. The overlay controller allows the 
display of motion-video over a region of the 
bitmapped display device by enabling the 
real-time overlay of NTSC video frames onto 
the identified region of the main display 
bitmap • 

Audio and Visual Peripheral Transducers 

These peripherals include input devices such 
as an NTSC camera to input motion-video, a 
microphone to input audio, and a 600 DPI 
color scanner to input high-resolution still 
images. Output devices include a 17" CRT 
display (1280 x 1024 resolution that can 
display 65,535 colors) for bitmapped and 
motion-video output, a loudspeaker for audio 
output, and a color laser printer for 
hardcopy photograph and document output. 
Audiovisual devices may plug into analog 
signal ports on adapter boards designed 
specifically for the purpose of PC bus 
interface, or into standard digital computer 
ports (according to their own unique 
interfacing requirements) . 
Media Access Control Device Drivers. 
Device drivers must be provided for the audio 
and video adapter boards (including the 
overlay controller) enabling the 
initialization, configuration, shutdown, and 
querying of each. System device drivers must 
be available to input scanner images, output 
printer images, and control system data 
ports, among other standard system services. 
Network Interface Unit (NIU) 
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A network interface unit roust provide the 
physical link to the network- It needs to 
support a minimum transfer rate of 128 kbit/s 
through a plesiochronous network (see 
U. Black, ATM, Foundation for Broadband 
Networks, Englewood Cliffs, New Jersey, 
Prentice Hall PTR, pp. 36-37, 1995) such as 
that provided by the Integrated Services 
Digital Network (ISDN). In the case of a 
host PC, the physical network connection 
extends to an ISDN phone jack, from an 
adapter card plugged into one of the 
computer's expansion slots. A fully-digital 
ISDN modem device is usable for this purpose. 
Network Protocol Stack 
The network interface must provide 
programmable software control of the physical 
network service, and in the case of the 
recommended ISDN configuration,. ISDN network 
protocol software must provide accessibility 
to one or more b-channels (for encoded 
audio/video data) and to a d-channel for the 
out-band signaling required for H.320 
protocol implementation. Data packets from 
the system must be directly accessible for 
synchronous transfer to and from the 
decoder/ encoder devices (audio and video 
CODECS) . 

ISDN Basic Rate Interface (BRX) 

For the preferred ISDN network interface, the 
ability to establish a connection supporting 
128 kbit/sec is generally accepted as the 
absolute minimum bandwidth needed to support 
a primitive motion-video image (with a 
concurrent audio signal) across the ISDN. A 
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typical BRI installation is utilized as a 
2b+ld channel configuration- For most 
purposes, a triple-BRI, or composite line 
configuration (384 kbit/sec) is preferable, 
5 as it is capable of producing an image closer 

in quality to that is generally considered 
acceptable in other video applications. 

System Development Requirements 

Developing a VMCS from preexisting hardware 
10 components is a combined system and application software 
development effort. Initial development of a VCO to 
control a set of devices is a significant undertaking 
that involves careful interface to device control 
software, and implementation of many of the specific 
is protocols residing under the H.320 rubric. While 

implementation of the prototypical VCO kernel is non- 
trivial, diligence is repaid many times over in that 
nearly all of the kernel source code is propagated, in 
rote fashion, to create a new VCO that can readily 
20 support a new set of devices. The client application 
binaries are directly re-releasable — client programs 
are fully device-independent and run over any VCO built 
to specification. Requirements to implement a VCO are 
outlined as follows: 
25 • VMCS Disclosure provides the necessary 

description of a Virtualized Multimedia 
Connection System to derive a design for an 
actual implementation. A complete set of the 
ITU-T recommendations referenced in ITU-T 
30 Recommendation H.320, are a necessary adjunct 

to the implementation and testing of fully 
compliant protocol implementations (see 
REFERENCES) . 
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C++ software Development System or a 

functionally equivalent object-oriented 
development system must be used to create 
both the VCO (server) and client portions of 
the VMCS. Full implementation of the 
referenced AT&T C++ language must be 
supported. 

Developer Toolkits provided by hardware and 
software OEM's, whose components are to be 
incorporated as VCO components, is essential 
to porting the device- independent VCO kernel 
to a new multimedia connectivity sub-system. 
Software tools to create the graphical user 
interface modules (such as exception handler 
message boxes and configuration displays) 
must also be available. 



Software Development Considerations 

To restate the purpose of VMCS server components: 
it is the primary directive of every VCO to bind, 

20 dynamically at run-time, a connectivity source to a set 
of transducers; and do so in such a way that the service 
provided to client applications serves as a mechanism to 
share spectral information between interconnected 
stations in the use of it, no consideration is given to 

25 any intermediate data transmission methods employed. It 
is the responsibility of the VCO implementer, to ensure 
that sound and light directed to and from the remote 
station, are somehow seamlessly, automatically, and 
transparently transited over the void that may exist 

30 between data streams associated with the source of 
connectivity, and those associated with the local 
transducers. Most systems utilize an integrated 
audio/video hardware design to provide a direct analog 
signal link between these parts — consider those 
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manufacturers mentioned in the Background section — but 
this model is crippling to the station in its other 
purposes for reasons aforesaid. 

The operating system type specified for this 
5 system is characterized by the ability to spawn threads 
that run concurrently at specified priorities. They can 
be utilized to support transparent (to applications 
running in the foreground) real-time data streaming 
facilities. Data streams to/from connectivity sources 

io can be attached to/ from transducers, so as to bridge any 
gap between discreet devices installed separately in the 
system; sharing data between separately installed devices 
requires read/write operations executed by the 
microprocessor (there is no direct analog signal 

15 connection between devices on different adapters) . With 
the specified operating system type, a station can take 
advantage of the multiprocessor personal computers that 
would support the transfer of data at very high speeds 
(between devices in the system) , even at rates sufficient 

20 for normal system operation, while processing audio and 
video in real-time. 

Whatever mechanism is used, hardware or software, 
the VCO implementation must create the operational 
context in the system, dynamically when invoked, to move 

25 data between system components. It must do so in a way 
that is fully protected, secure, and unaffected by other 
system activities. The creation of the sub-system's 
operational context must be transparent to the client 
application, as must its destruction at session's end. 

30 VCO SOFTWARE IMPLEMENTATION 

A VCO is mostly comprised of software objects 
whose member function implementations are overridden by 
more derived versions of themselves that provide 
structured access to the services of installed adapter 
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devices . As the VCO architecture is a direct application 
of software object technology, to elucidate the details 
of its embodiment entails discussion of its components in 
terms of a class derivation hierarchy. Next follows 
s examination of the VCO's class structure. 



VCO Class Derivation 

One VCO implementation encapsulates one specific 
sub-system configuration that exhibits a particular set 
of properties (capabilities) that defines its unique 

10 service profile — unique in the set of standardized VCO 
operations it can support, but no different from any 
other VCO in the way it presents them to client 
applications . Correspondingly, each VCO is no different 
from any other in the way it is implemented. In fact, 

is there are a number of implementation principles to 

consider prior to VCO design specification, thus speaking 
generally towards application of the concept... 

• Afore derived classes in the VCO are more 
device-dependent, ranging from the device- 

20 independent VDI classes, to the device- 

dependent class PDI. 

• Less derived classes in the VCO are less 
device-dependent, wherefore all VCOs contain 
the same device-independent kernel (that is 

25 comprised of class VDI and all those from 

which it is derived) . 

• More derived classes are more time critical, 
ranging from the VDI that responds to 
occurrences of events in OS-scheduled time 

30 slices, to the PDI that can queue events 

during interrupt service routines, invoked in 
real-time by device requests for interrupt. 

• More derived implementations (more device- 
independent default implementations) of VCO 
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virtual members substituted with a more 
suitable implementation overriding them with 
one more device-specific (residing in a more 
derived class) ; that is, a default function 
is provided by the VDI, which the programmer 
can override in his particular implementation 
of the same feature. 

In most cases, mare that 90% of the VCO 
source code is reused in the next VCO 
implementation without modification, due to 
the imposition of rigorous functional 
constraints (by the VCO architecture) on its 
class structure. 

A pure virtual member interface in the 
device-independent VDI, to more derived 
device control members in the device- 
dependent PDI, impose strict isolation of 
logical from physical operations. This 
isolation of logical operations from physical 
device operations, is realized by exploiting 
object-oriented software language constructs 
integral to the language itself; structural 
integrity and layering of operations in the 
VCO is enforced at the most fundamental level 
of source code expression. The device control 
members used by the VDI (to lend physical 
device control to the implementation of its 
algorithms) are accessible directly in the 
same class, but the underlying device control 
mechanism is (for all intents and purposes) , 
in one more derived and not directly 
addressable. Resultant ly, any changes to the 
way these more derived device control members 
are implemented, are beyond its discerning. 
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• Design-level isolation of logical and 

physical device control mechanisms in the VCO 
architecture, are incorporated so as to 
intentionally expose a well-defined, readily 
exploitable "fissure" in its layering model, 
whereby the core technology is rendered 
amenable to specific extensions of concept. 
The implementations of certain system designs 
are significantly reduced in expense and 
difficulty as a direct result of the well- 
defined logical-to-physical mounting 
mechanism. Some applications of concept 
advanced by its accessible mounting mechanism 
include: 

• Rapid prototyping and redeployment for 
new sub-system configurations 

• Distributed VCO development by VDI and 
PDI development teams 

• Microcoded or embedded PDI 
imp 1 eme nt a t i on s 

• Distributed media control systems 

• Remote station control and diagnostics 

The class derivation diagram depicted in FIG. 6 
shows the classes that directly comprise the VCO, as well 
as adjunct classes (Notifier and MCO) that are used to 
implement its feature set. Every component shown is used 
in every VCO implementation exactly as shown. Class VDI, 
being the virtual Device Interface used by clients to 
access the VCO's encapsulated sub-system, is the only 
class, besides the public constructor and destructor in 
class VCO, that contains public member functions. The 
symbols used to describe the various relationships 
between classes are mostly proprietary to this 
disclosure, as no widely-used convention to graphically 
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express object-technology concepts has been adopted by a 
major standards organization. Symbolic conventions used 
here are shown in FIG. 1. 

Summary of VCO Class Derivation 

s Each VCO is a composite derivation of the six 

classes: Terminal , Exception, Event, VDI, VL, PDI, and 
VCO. In the order of least to most derived, the 
derivation sequence for the VCO itself, proceeds as 
follows: 

10 • Class Terminal enables the VCO to send text 

messages to a set of character output 
devices, or receive text messages, that are 
subsequently interpreted as commands. Since 
the VCO terminal can be programmed to use the 

15 VCO notification mechanism as a virtual 

output device, the class contains a pure 
virtual member used to direct text output to 
a Notifier Object configured for such 
purposes. This member is overridden by a 

20 supporting member function in the more 

derived class Event, and this override must 
be present for class terminal to compile. 
• Class Exception is derived from class 

Terminal, and is defined to contain member 

25 functions and data related to reporting fatal 

errors by responding in some pre-conf igured 
way. In the most primitive sense, the only 
service that class Exception must be able to 
access is some method to relay the fact that 

30 the exception occurred, and by inheriting 

members of class terminal, it can. Class 
Exception also has a virtual function used to 
shutdown the VCO when an exception occurs. An 
override in the VDI provides an 
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35 



implementation that shuts down the VCO, as 
expected during fatal errors. 

Class Event is derived from class Exception, 
and is defined to contain the VCO event 
manager , which in turn manages the 
notification mechanism. It maintains a linked 
object list of Notifier Objects which are 
themselves each individually derived from the 
NOTIFIER data structure. Every Notifier 
Object is a protected class that is created 
by class Event, and is a friend to it. Class 
Event, but no other, can create, delete, or 
access class Notifier members directly except 
members of class Event, thus the Notifier 
Objects are essentially creatures of it. The 
event handler is the VCO's "proxy 11 to the 
linked list of Notifier Objects. Class VDI is 
a protected derivation of class Event. It is 
defined to contain a large set of members 
that comprise the VCO Software Control 
Interface, and a number of device-independent 
protocol support procedures. Inheriting the 
services of classes Terminal, Exception, and 
Event, it is capable of presenting the entire 
VMCS connectivity services through the member 
functions of a single binary software object; 
that is, one instantiated upon construction 
of a class derived from it. 
Class VI* is derived from class VDI, and 
provides a location for an implementation- 
dependent set of routines to map physical 
device control operations and responses 
to/ from the logical representation 
manipulated by members in the VDI. Most of 
its members are private to it, and narrowly 
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focused in scope. Entry points to translation 
and mapping services are made public to more 
derived classes that wish to utilize them. 



within it, private definitions and 
implementations of member functions that 
override the pure virtual device control 
members used in the VDI to invoke the 
services of physical devices in the 
encapsulated multimedia connectivity sub- 
system. The implementation of the pure 
virtual overrides utilize members in the VL 
to translate and map the structure of 
arguments and input/ output data syntax to 
that expected by the VDI implementations. The 
PDI contains mechanisms to access the VCO 
Media Control Object Device Control Mechanism 
(Media Control Objects) . This mechanism 
relies upon the maintenance of a linked 
object list of instances of class MCO 
maintained much like the linked list of 
Notifier Objects in class Event. Class MCO is 
derived from an MCOPARAM data structure that 
serves as a general purpose repository for 
device control information as associated to a 
particular signal from a particular device. 
As with the administration of Notifier 
Objects, instances of class MCO are directly 
accessible only by the PDI; only the PDI may 
directly examine, modify, and invoke their 
members. The design of the VMCS is to promote 
its utilization in a variety of operating 
environments that include distributed 
systems, remote access across a network 
connection, and text command (teletype) 



Class PDI is derived from VL, and contains 
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interface via dumb terminal. Members of class 
MCO are accessible to underlying Media Access 
Control software, and MCO implementations 
make calls to the same to invoke device 
5 services . 

• Class VCO is derived from class PDI, and 

functions as the capstone for the VCO class 
structure. The only members it inherits from 
its parent classes are the public members 
o that comprise the SCI in the VDI. Its 

constructor and destructor call those of its 
parent classes, thus it invokes those of the 
VDI to create and destroy the VCO session. 
Class VCO contains all additional 
5 implementation-specific entry points (object 

members) that are presented to client 
applications, including extensions to the 
VMCS that are not directly related to 
controlling the connectivity session. All 
"> client applications proceed with the 

expectation that the invocation of VCO 
services will always be accomplished using a 
pointer or reference to class w VCO M . 

Class Components 

> Next follows detailed descriptions of the 

operations that must be implemented by each class 
comprising the VCO. 



Class Terminal 

Provides full implementation of the VCO terminal 
30 services by maintaining a list of output devices for the 
output terminal, and writing all text message sent to the 
terminal output port to every device on this list. Text 
messages sent to the terminal input port are assumed to 
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be VCO text commands- They are parsed into tokens , 
decoded, and executed as SCI commands* The sub-components 
residing in this class are listed below, with an 
accounting of the specific operations for which they must 
5 provide support- 

• Terminal Stream I/O Device Controller 
Operations supported by this sub-component 
must include the following: 

• Add output device to list 

10 • Remove output device from list 

• Write text message to output device 

• Text Command Decoder 

Operations supported by this sub— component 
must include the following: 
is • Parse text command message to command 

token list 

• Verify command syntax 

• Execute command token list as SCI 
command 

20 • Text Command Encoder 

Operations supported by this sub-component 
must include the following: 

• Verify command syntax 

• Translate SCI call to text command 
25 message 

• Linked Terminal Stream I/O Device List 
The list itself is implemented as a linked 
object list, where each object contains the 
member functions and member data necessary to 

30 transmit data to the file, device, signal, or 

data port referenced by it. 
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class Exception 

Provides full implementation of the VCO exception 
handling operations that include reporting the occurrence 
of the exception, and subsequently shutting the VCO down. 
Additional features of this component include the 
maintenance of an enable/disable flag that is tested by 
every public member function upon entry into the VCO; a 
disabled VCO must reject any call into it, and return the 
"Disabled- result code to the caller. There are a number 
of flags that can be used to configure the exact modality 
used by the exception handler to respond to exceptions, 
and each modality must be supported by the exception 
handler implementation, in accordance with the 
definitions shown in FIG. 6A. The sub-components residing 
in this class are listed below, with an accounting of the 
specific operations for which they must provide support. 
• Exception Handler 

Operations supported by this sub-component 
must include the following: 

Process VCO exceptions accordingly (see 

FIG. 19) 

Provide for capability to display debug 
information message box 

Display "user" information message box 
Send text information message to 
terminal 

Trigger Notifier on exception 
Trigger VCO disabler mechanism on 
exception 
Disabler Mechanism 

Operations supported by this sub-component 
must include the following: 

• Maintain VCO enabled/disabled flag 

• Provide for query of enabled/disabled 
flag (see FIG. 19) 
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• Invoke system shutdown utilizing virtual 
override in VDI 

Class Event 

Provides full implementation of the VCO event 
5 management operations. A list of Notifier Objects is 

maintained, and a mechanism to trigger them is contained 
in this sub-component. The VCO event queuing and 
dispatching mechanisms are located in this component, 
though critical section handling may be located in the VL 

io to make use of special operating system support for 
semaphores and thread blocking features. There are 
thirty-two (32) distinct events that have been 
standardized for VMCS use. FIG. 6C shows the symbolic 
identifiers for these events, and provides concise 

15 definitions for each. The physical source of the event is 
labeled as either hardware (HW) or software (SW) , and 
accompanied by a code that goes on to further clarify the 
specific system component from which the event is likely 
to (though not necessarily) emanate. 

20 VCO developers creating a VCO to work with a new 

device set, roust identify the most reliable source for 
VCO events originating in hardware, and then map vendor- 
specific representations of the event to those virtual, 
standardized, and described in FIG. 6B. Third-party 

2 5 device drivers in the MAC layer may not provide access to 
events identical in meaning or context to those cataloged 
by the VCO; some interpolated or emulated derivation 
(from events closely related) may be necessary for a 
compliant indication of the standardized occurrence, and 

30 any member functions created to approximate the 

representation of one such only marginally identifiable, 
should reside in the VL layer for invocation by members 
in the PDI. 

The event manager is also responsible for managing 
35 the flow of trace information to its terminal output 
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port. The sources from which trace information emanates, 
can be programmed in an additive fashion, by specifying a 
trace output profile . There are a number of flags, 
applied to express this profile as a logical combination 
5 of trace output source locations within the VCO's works, 
and each modality must be supported by the event manager 
implementation, in accordance with the definitions shown 
in FIG. 6B. The sub-components residing in this class are 
listed below, with an accounting of the specific 
10 operations for which they must provide support. 

• Notifier Object List Manager 
Operations supported by this sub-component 
must include the following: 

• Create and add new Notifier Object to 
15 linked Notifier Object List 

• Remove Notifier Object from list and 
delete 

• Set Notifier Object triggers 

• Get Notifier Object data 

20 • Lock Notifier Object List against 

add/remove operations while triggering 

• * Unlock Notifier Object List to allow 

add/ remove operations 

• Notifier Object List 

25 The list itself is implemented as a linked 

object list, where each object contains the 
member functions and member data necessary to 
configure the Notifier Object's triggering 
profile, as well as to actually trigger it to 

30 deliver notification to its associated 

Notification Receiver Object. 

• Notification Triggering Mechanism 
Operations supported by this sub-component 
must include the following: 
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• Trigger Notifier Objects in Notifier 
Object List (see FIG. 10) 

Event Dispatcher 

Operations supported by this sub-component 
must include the following: 

Dispatch event (see FIG. 11) 
Start dispatcher 
Stop dispatcher 
Set dispatcher rate 
io • Configure dispatcher 

• Event Queue 

Operations supported by this sub-component 
must include the following: 

• Add event to queue (see FIG. 11) 

15 • Remote event from queue (see FIG. 11) 

• Flush queue 
Class Notifier 

Provides full implementation of the VCO Notifier 
Object (NO) . Each NO is a self-contained reporting 

20 mechanism called a thunk. This thunk must be created by 
any class that wishes to be informed of the occurrence of 
a VCO event. The thunk provides a globally defined entry 
point to the address space of the instantiated class 
object that is to receive notifications, and the thunk 

25 retains knowledge of the exact class name and specific 
class member designated to receive notifications (from 
the NO residing in the VCO itself) . The NO stores a 
pointer to this global entry point (the thunk) , a pointer 
to the Notification Receiver Object (NRO) / and a pointer 

30 to the NRO's Notification Receiver Member (NRM) that is 
the ultimate destination for delivery of notification. 
The NOTIFIER data structure from which the Notifier 
Object is derived, contains all of this information, the 
achieved objective in its tracking to enable an immediate 

35 conveyance of a unit of system event information (a 
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standard VCO event) directly from a driver-level 
component to the application, as soon as there exists an 
opportunity for the operating system to run the 
interested application. With regards to VMCS 
implementations and their notification mechanism, system 
designers should first reflect upon the following: 

• Notifications are designed specifically to 
operate like system interrupts, independent 
of user interface event queues. Like 
interrupts, they require service only in 
response to very specific occurrences to 
which they are programmed to respond — 
service routines do not have to test for a 
wide range of possible triggering events, but 
can act directly with simple, well-defined 
operations. 

• Notifications from the VCO are virtually 

unaffected by user-interface operations, and 
events are never lost to "queue-full w 
conditions. They are fast, configurable, 
flexible, and offer a measurably more 
reliable feedback mechanism than the typical 
GUI event delivery mechanisms, but 
expectantly can interrupt drawing operations 
in progress. Drawing operations, to display 
information delivered by a Notifier Object, 
are best executed from a specific painting 
routine, whose invocation is governed by the 
receipt of paint messages from the GUI — 
painting messages and graphics to the display 
with each notification can prevent the GUT 
from processing messages in its own event 
queue. 

• Consistent with the previous point, NRMs 

should be constructed as high-level interrupt 
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service routines that insert an event into 
the application's event queue (GUI event 
stream) , or spawn a new thread to exact some 
effect on the system, and return immediately . 
5 To delay processing on a notification thread 

could delay notification to other VMCS 
objects (if a single thread is used by the 
triggering mechanism to trigger all NOs) . 
Beyond delay, none of the usual problems 
io associated with delayed interrupt processing 

occur since the VCO queue retains all events 
till processing is resumed; no information is 
ever lost. Further, VCO events are but 
shadows of real-time events that will have 
is long since been serviced in real-time, 

according to the methods implemented by 
driver-level vendor-specific components. 
However, correct designs for systems will 
service all outstanding event notifications 
20 and return long before the VCO dispatcher is 

ready to remove another event from its queue. 
The constructors of Notifier Objects add them to a 
linked object list upon construction, and remove them 
from the list upon destruction; their structured 
25 integration into a linked storage format is managed 

automatically. An accounting of the specific operations 
for which this class must provide support are listed 
below: 

• Notifier Object Operations 
30 Operations supported by this sub-component 

must include the following: 

• Find Notifier Objects to trigger in 
linked object list (see FIG. 10) 

• Trigger individual Notifier Object in 
35 list (see FIG* 10) 
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Set Triggers 
Get Statistics 
Reset Statistics 



Class VDX 

s Provides full implementation of the VCO Software 

Control interface (SCI), along with a number of private 
support functions. Any device-independent routine 
necessary to vco implementation resides in this class. 
The header file VDI.H (see Appendix) contains all of the 
10 constants, enumerations, and data structures used by both 
server and client portions of the VMCS. Following those 
definitions, is that of the SCI. These member functions 
are the virtualized definition of the VMCS control 
mechanism from the client application's perspective, and 
is are the only public members of the VCO; notably excepted 
is the VCO constructor and destructor in class VCO. Not 
shown in VDI.H are the device- independent call and 
protocol management routines that provide support for the 
VCO connectivity sessions. They are implementations of 
20 various Recommendation H.320 protocols. The session- 
related sub-components residing in this class are listed 
below, with an accounting of the specific operations for 
which they must provide support. 

• Network Session Operations 

Operations supported in this group of member 
functions have public entry points that are 
represented in the SCI (see Section entitled 
VDI Header File in Appendix) . They are noted 
here to reference figures that detail their 
30 flow control pathways. The Network Session 

operations must include the following: 

• Construct VCO (see FIG. 24) 

• Destruct VCO (see FIG. 24) 

• Open VCO (see FIG. 25) 
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• Close VCO (see FIG. 26) 

• Make call to remote station (see FIG. 
27) 

• Execute multipoint call operation (see 
FIG. 28) 

• Hang-up call or line (see FIG. 29) 
Media Control Object Device Control 
Operations 

Operations supported in this group of member 
functions are accessed by the public 
audiovisual/data signal switching control 
members in the SCI (see section entitled VDI 
Header File in Appendix) . A query flag passed 
during a call to this member function 
determines whether or not a request for 
service or capability query is invoked. 
Operations supporting the service and query 
requests must include the following: 
Media control operation service request (see 
FIG. 20) 

• Media control operation query request 
(see FIG. 21) 

Device- independent Call Controller 
Operations supported in this group of member 
functions respond to line state events from 
the Device Event Processor, to manage the 
connectivity session. Call control related 
members must include the following: 

• Enter call controller and process line 
event (see FIG. 14) 

• Execute procedure to handle incoming 
line disconnected (see FIG. 15) 

• Execute procedure to handle incoming 
line dialed (see FIG. 16) 
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Execute procedure to handle incoming 
line ring (see FIG, 17) 
Execute procedure to handle incoming 
line ringback (see FIG. 16) 
Execute procedure to handle incoming 
line connected (see FIG, 16) 
Execute procedure to handle incoming 
line busy (see FIG. 16) 

Reset call data to default states (see 
FIG. 18) 

Restore default connected device modes 
(see FIG. 18) 

Set connected device modes (see FIG. 18) 
Device-independent Capability Exchanger 
Operations supported in this group of member 
functions contribute to implementing an 
algorithm that employs an H.221 mode- 
capability cross-reference table to determine 
if the connection between logical and remote 
stations can support a given H.221 device 
mode; that is, it compares the capability 
associated with the mode to the logical 
intersection of the capabilities of the local 
and remote stations. Capability exchange 
operations are internal to the VCO, and must 
include the following: 

• Accessibility to an H.221 node* 
capability cross-reference table 

• Determine if connection supports mode 
(see FIG. 12) 

• Determine if capability is associated 
with mode (see FIG. 13) 

• Determine if local station supports 
capability (see FIG. 13) 
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• Determine if remote station supports 
capability (see FIG, 13) 

• Device- independent Device Event Processor 
A member function in the VDI is a 

5 Notification Receiver Member that receives 

notifications of device events from a 
Notifier Object created by the VCO at the 
time of its construction. Any events in FIG. 
6C, whose source is identified as hardware, 

10 is considered a device event, and the Device 

Event Processor responds to them to maintain 
the current connectivity session. Device 
events are processed according to a specific 
algorithm that routes them through 

15 appropriate control flows depending on their 

particular category (see FIG- 23). 

• Pure Virtual Device Control Members 

There are no implementations of these members 
in class VDI; only the member declarations 

20 are present (see section entitled VDI Header 

File in Appendix) . These members are used 
extensively by implementations of other VDI 
members to provide the device interface for 
all operations that access vendor-specific 

25 driver components and their underlying 

physical devices. 



Class VTj 

Provides full implementation of any members 
necessary to convert, translate, map, or interpret 
30 operations and data formats between conventions used by 
logical controls in the VDI, and Physical Device 
Interfaces accessed by the PDI (MAC layer components) . 
This class may vary greatly in the number of member 
functions it must contain for a particular VCO 
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implementation. The header file PDI.H (see section 
entitled Physical Device Interface File in Appendix) 
contains a definition of an empty class VL to show its 
role in the derivation of the VCO. Visualization 
5 operations are unlikely to be device -independent, however 
the categories of operations they commonly must implement 
are preserved across most VCO implementations, and are as 
follows: 



20 Class PDZ 

Provides full implementation of the VCO device 
control interface, including a number of operations to 
interface operating system services. A pure virtual 
override member must be implemented to support the 

25 operations defined for the pure virtual device control 
members defined in the VDI (see section entitled VDI 
Header File in Appendix). The header file PDI.H contains 
the definition of class PDI (see Appendix) and shows its 
role in the derivation of the VCO. Implementations in 

30 class PDI have no restrictions on the way they interface 
devices. Media Control Objects (instances of class MCO) , 
are the preferred mechanism. At the time the VCO is 
opened, when its devices are initialized, the PDI creates 
an array of Media Control Objects that describes the 
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Virtualization Operations 

• Software Component Load/Initialization 

• Software Component Unload/ Shutdown 

• Configuration Information Access 

• Data Exchange Syntax Mapping/ Emulation 

• Call Event Mapping/ Emulation 

• System Information Mapping/ Emulation 

• Capability Exchange Mapping/Emulation 

• System Exception Mapping/ Emulation 

• Media Access Control Mapping/Emulation 

• Protocol Mode Mapping/ Emulation 



080OM3A1 J, 



WO 98/09213 ©a |Sf® PCT/US97/1S018 

- 119 - 

available, and expected-to-be-available, audiovisual/data 
signal types. These Media Control Objects contain the 
member functions and data structures needed to control 
the device that is the source of, or destination for, the 
5 signal they represent to the VCO. The next section 
entitled MCO Device Control Mechanism goes on with a 
further discussion of the Media Control Object Device 
Control Mechanism. The sub-components residing in this 
class are listed below, with an accounting of the 
io operations for which they must provide support. 

• Pure Virtual Device Control Member Override 
Operations 

Operations supported by this group of members 
are best described by the descriptions of the 

15 pure virtual member functions defined in 

class VDI (see "Class VDI") . The pure virtual 
overrides residing in class PDI are 
implementations of the pure virtual device 
control members declared in class VDI (see 

20 section entitled VDI Header File in 

Appendix) . 

» Device Capability List (H.221 Capability BAS 
Codes) 

A list of device capabilities is stored in 

25 the VDI (see section entitled Bit-Rate 

Allocation Signal Header File in Appendix) , 
but must be maintained by the PDI. A local 
capability list in the VL is copied into the 
VCOPARAM structure in the VDI during VCO 
30 construction. Incoming capabilities from the 

remote station are written to the remote 
capabilities field of the VCOPARAM structure, 
by callback members in class PDI, and are 
called by the connectivity protocol stack 
35 when capabilities are transmitted from the 
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remote station. VCO device capabilities are 
represented as device- independent constants, 
so there may be a necessary mapping operation 
from the BAS code (or proprietary) 
representations used by the connectivity 
protocol stack to/ from those defined for the 
VMCS. 

• Device Modes List (H.221 Device Mode BAS 
Codes) 

A list of all H-221 device modes is kept in 
the PDI as a reference. This list is used to 
determine if a mode is standard, non- 
standard, of a given type, or invalid. 

• Device Event Linkages to Queue 
In order for the PDI to be informed that 
device events have occurred, a number of 
callback functions are declared in this 
class. Such callbacks can typically be 
classified and implemented as follows: 

• Connectivity Protocol Stack Callback 
Members are called by routines in the 
software modules that implement the 
connectivity protocol. In connectivity 
protocol stacks encapsulated by the VCO, 

25 the callbacks come from the OS I 

transport layer (or its equivalent) . 
They call the VCO to report any changes 
in line states, the arrival of BAS codes 
from the remote station, and for a wide 
variety of status-related events, as 
defined in FIG. 6C. 

• Media Access Control Callback Members 
are called by routines in the device 
drivers that comprise the MAC layer. 
They call the VCO to report changes in 



35 



V2ID: Q80G213M_L> 



WO 98/09213 




PCT/US97/15018 



- 121 - 

device states, results of device 
operations, and a wide variety of 
status-related events, as defined in 
FIG. 6C. 

5 Upon receiving an event from any callback 

function, the vendor-specific event is mapped or 
translated to one of the standard VCO events, and added 
to the VCO event queue* Routines in class VL may be 
called for this purpose. 

io class VCO 

There are no specific components to implement in 
this class. Extensions to the VCO feature set, beyond 
those related to control of the encapsulated sub-system, 
should be added as members to this class; it is the place 
is specifically intended for such enhancements. The header 
file VCO.H contains the definition of class VCO (see 
section entitled General VMCS Header File in Appendix) 
and shows its role in the derivation of the VCO. All 
client applications must include this file in order to 
20 access the services of the VCO itself. Class VCO is the 
class that is constructed by the client, and it presents 
to this client a number of public member functions 
described as follows: 

• Public VCO Members Available to Client 

25 • VCO is the constructor of the VCO, and 

invokes the constructors of all less 
derived classes when invoiced. 

• -VCO is the destructor of the VCO, and 
invokes the destructors of all less 

30 derived classes when invoked. 

• Inherited Public Members from the SCI 
are all presented to the client 
application as members of class VCO. 



I3A1 I > 



WO 98/09213 




PCT7US97/I50I8 



- 122 - 

Implementation-dependent Extensions can 
declare public member functions in class 
VCO that offer their services to the 
client application seamlessly with other 
vco functions. 
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MCO DEVICE CONTROL MECHAMT g ff 

The device control diagram depicted in FIG. 7 
shows how the VCO is able to reference the devices in its 
encapsulated sub-system as configurable representations 
of the data streams that they generate, process, or 
redirect. Client calls to the SCI are shown to invoke SCI 
members that, according to their specified function, rely 
on calls to pure virtual device control members for their 
implementation, thus not all SCI members are included in 
the diagram. The sixteen default Media control Objects 
are arranged in the drawing to clearly demark the low- 
level, vendor-specific component to which they 
correspond, and manipulate when affected by PDI calls to 
their members. Vendor-specific MAC components should be 
considered bi-directional — they support control 
pathways and data streams to and from a media control 
sub-system — and the different types of transducers 
reguired for each direction are clearly evident. 
Concordant ly one finds the "audio" objects reference a 
MAC component supporting audio input and output, and to 
that single MAC component is connected both microphone 
and speaker. PDI calls made directly to the connectivity 
protocol stack and MAC components are not shown 
explicitly in the drawing, as the exact structure of 
their interactions are left to the implementer ' s 
discretion. 
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Summary of Device Control Mechanism 

Client calls to the SCI invoice members that often 
require the support of the encapsulated multimedia 
connectivity sub-system in their implementations • The 
5 implementations of SCI members , such as "Open" and 
"Call", make requests for physical device control 
services by utilizing at least one of the pure virtual 
device control member functions declared in class VDI; 
these members are private and entirely separate from the 

10 public SCI members offered to clients • The PDI contains 
overrides for these pure virtual device control members. 
These overrides invoke the appropriate device operations 
by making calls directly to the connectivity protocol 
stack or MAC layer components, as is appropriate to the 

is desired device control operation. Implementations of the 
pure virtual device control overrides must perform any 
and all interface to vendor-specific hardware and 
software components necessary to fulfill the specified 
expectation of the pure virtual device control member in 

20 the SCI. 

If the particular SCI member, called by a client, 
is MediaControl, the method of interface to the physical 
device is different from that used for call and protocol 
operations; its purpose is to switch or configure the 

25 audio, video, image, or data signals represented as 

virtualized system objects, or Media Control Objects- In 
this case, the pure virtual override for MediaControl, 
implemented in the PDI , then manipulates the members of 
Media Control Objects that have been created to represent 

30 the various available signal types. Depending upon the 
exact nature of the request, audio, video, image, and 
data signals are combined, redirected, displayed, or 
routed to local devices or the remote station. The Media 
Control Objects can also be used to set various modes 

35 (associated with the signals) by directly controlling the 
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device associated with it. The operation of the Media 
Control Object device control system is detailed as 
follows : 

• Primarily there exist sixteen default Media 
Control Objects, as shown on the right side 
of FIG. 7. 

• There is an input and output object to/from 
the remote station for each signal type (see 
FIG. 7A), for a total of eight objects 
representing information shared between the 
local station and the remote station. 

• There is an input and output object to/ from a 
local device for each signal type (see FIG. 
7A) , for a total of eight objects 
representing information shared between the 
local station and its local environment. 

The objects are only created when the signal 
they represent is within the capabilities of 
the system to support. They are only enabled 
when the signal they represent is actually 
available for access. 

• Any number of Media Control Objects can be 
created in the VCO to control more devices 
and data channels, as determined by their 
detected system device availability by the 
VCO. 

• Each Media Control Object, representing a 
specific signal type and direction, can be 
attached, or "plugged into" another Media 
Control Object that is compatible in both 
signal type and direction; For example, an 
audio source from a local device (microphone) 
can be attached to an audio output to a 
remote station, or a video input from a 
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remote station can be attached to an output 
to a local device (video display) 
Each Media Control Object, regardless of 
signal type, contains a data structure that 
reflects the various states and modalities of 
the signal. Member functions for each Media 
Control Object, allow them to be manipulated 
as independent, uni-directional channels. 
Certain Media Control Objects can be combined 
into composite media control objects that 
describe a complex signal type, such as 
multiplexed audio/ video information. The 
objects can also be combined with objects 
that subject them to a specific transform, or 
split/ join configuration. 

Setting the parameters of a source/ input 
object invokes a sub-system (driver- level) 
attempt to change the settings of the source 
device or station, whereas setting the 
parameters of a destination/output object 
attempts to change the settings of the 
destination device or station. 

Audiovisual/Data Signal Switching Mechanism 

Device control operations are made directly 
25 available to VCO Client applications through the 

implementation of the MediaControl SCI member function, 
along with some related members that assist in the 
manipulations of these objects. The SCI members map to 
essentially identical pure virtual device control members 
30 implemented in the PDI. The switching of signals and 
device modalities generally takes place by selecting 
constants from various enumerated categories (see section 
entitled VDI Header File in Appendix) , and presenting 
them to the VCO with the MediaControl member. The format 
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of the arguments is constructed so that the specified 
operation applies to the currently assigned default Media 
Control Object for the specified Media Control Object 
type (see FIG. 7A) .. For example, a command to mute the 
s input microphone would likely reference AudioSrc as the 
Media Control Object type. Handles are used to assign 
various non-default Media Control Objects as the default 
(one of the sixteen) for a given type. The continuous 
linear enumeration of all possible constant arguments 

10 used for Mediacontrol function calls give each setting a 
unique numerical identifier, and thus each can be 
associated with a unique string token. The argument 
formats for all of the Mediacontrol calls are detailed in 
the source code section (see section entitled VDI Header 

is File in Appendix) . 

Media Control Object Physical Structure 

Each Media Control Object is a class object 
privately derived from an MCOPARAM (see section entitled 
VDI Header File in Appendix) structure. Regardless of the 

20 signal type (audio/video/ image/data) represented by the 
Media Control Object, the MCOPARAM structure contains 
sub-records for all signal types. The programmer need 
only attend to the relevant section for the signal type 
for that object. There are a number of requirements as to 

25 the structure of the Media Control Objects physical 

structure, with regards to the specific details of its 
implementation . 

• All member functions and member data in the 
Media Control object, are protected, and can 

30 only be accessed by the PDI . 

• Class PDI is a friend to all instances of 
class MCO. 
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• Class VDI cannot access any MCOs directly, 
except through specific members that are 
implemented by class PDI. 

• All MCO members presented to the PDI, should 
5 be simple, device-independent operations to 

manipulate the settings and operations 
precisely outlined by the audio, video, 
image, and data records contained in the 
MCOPARAM data structure. 

io • Each MCO should be fully cognizant of its 

signal type and signal direction, and 
prohibit operations that are inconsistent 
with its fundamentally characteristic 
properties, i.e. cannot attach audio output 

is to a video display. 

• The handle of a new MCO must be added to the 
VDI tables in DEVICEPARAJI when that MCO is 
created, and removed when deleted, such that' 
the client always has a clear picture of 

20 available system resources. 

• Events must be queued for each and every MCO 
operation executed . 

• Regardless of the complexity of underlying 
system components that must be initialized , 

25 addressed, or monitored to implement Media 

Control Object operations, it is critical 
that the designer reduce the invocation of 
such processes to simple operations described 
by the Media Control Object settings. 

30 MCO Interface to the Media Access Control Layer 

Each MCO controls the device underlying the 
signal it represents by making requests to the Media 
Access Control layer components that drive them. The PDI 

pure virtual override DevMediaControl presents settings 
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to the Media Control Objects, and the Media Control 
Objects then go on to map the setting to a physical 
device control operation. FIG. 22 shows the control flow 
for device control operations that are presented to MCI 
5 drivers that comprise the MAC layer. This diagram has 
greatly simplified the pathway from the VDI to the MCI 
driver, eliminating most of the interactions with the 
Media Control Object. In short, the PDI prepares a Media 
Control Reguest Record, and presents it to the 
io appropriate Media Control Object so that the object can 
fill in its fields, and present it to a corresponding MCI 
driver (see FIG. 22). Note that a device control 
operation initiated by the local station can result in 
the station assuming a new H.221 device mode, which is 
15 then transmitted to the remote station (if currently 
connected) for station synchronization, referred to as 
the "establishment of common modes" by Recommendation 
H.320. Finally, an event is added to the VCO event gueue 
describing the new Media Control Object setting that has 
20 taken place. 

STATION ATTACHMENT MECHANISM 

There are a number of considerations with regards 
to the system components that must be created to support 
the "attachment" between two interconnected VMCS 

25 stations. A pathway must be established between the two 
stations such that they can share text string commands 
streams. Once this pathway is available, the two stations 
must come to a mutual understanding how they will 
interact; that is, which station is the master, and which 

30 is the slave. 

Beyond the standard attachment mechanism 
described, a third station can control any one of a 
number of stations that are themselves interconnected in 
a conference. In this modality, a "third party" 



oocnj: <wo _ seoa2isM_L> 



WO 98/09213 



* 



PCT/US97/15018 



- 129 - 



controller, or "remote operator" can intervene in 
conference already in progress to assist, diagnose, or 
monitor one of the conferees. The details of designs that 
would accomplish this task are supportable by the VMCS, 
5 but beyond the scope of this disclosure. Below follows a 
description of the details for the VCO components used to 
implement the remote station attachment mechanism. 

Command Stream 

From the perspective of one end of the attached 

10 station pair, the command stream is bi-directional — to 
and from the remote station. A Media Control Object 
supporting text data output to the remote station, and 
another Media Control Object supporting text data input 
from the remote station, are created to encapsulate the 

15 data pathways. Since mostly text message data will be 
exchanged, the pathway need only support low bandwidth 
(less than 16 kbit/s) on an occasional (asynchronous) 
basis. Data can be transported out-band on a separate 
channel (such as an ISDN D-Channel) or in-band, perhaps 

20 multiplexed with video data. The data transport mechanism 
for message data can also be accomplished through a 
tertiary source using an entirely separate connection 
from that used for primary communication. All messages to 
the remote station are written to the Media Control 

25 Object encapsulating the pathway to the remote station, 
while messages arriving from the remote station generate 
events as they are received by the Media Control Object 
encapsulating the pathway from the remote station. 

Event Encoder 

30 This component converts binary event records added 

to the VCO event queue to a text event message 
representation, and then sends it to the remote station. 

A definition of the binary event record is provided (see 
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section entitled VDI Header File in Appendix) , however 
the exact text event message format is left to the system 
designer. Suffice it to say that the text message format 
used should be entirely universal to allow all VMCS 
5 implementation platforms to engage in "attachment* 1 . 

String tables in the Linguistic Controller areas of the 
VCO are used to convert the enumerated arguments to 
string tokens, whenever possible, while purely numerical 
arguments (such as parameters) are converted to ASCII 
10 hexadecimal strings. Each event message must minimally 
include the following information: 

• Event identifier 

• 32-Bit parameter 1 

• 32-Bit parameter 2 

15 • Source station identifier 

The event encoder is usually only accessed when 
the VCO is attached to a remote station- While the VCO is 
attached, the encoder is invoked by the VCO queuing- 
mechanism each time an event is queued. The encoding 

20 takes place using a separate thread of execution to avoid 
interference with device timing. 

Event Decoder 

This component converts text event messages 
received from the remote station and converts them to 

25 binary event records that are then added to the local 
VCO's event queue. This process is the inverse of the 
encoding process, and its success depends upon the 
consistency of the text event message format selected. 
The source station identifier tells the receiving VCO 

30 where the event came from, and the string tables in the 
Linguistic Controller are used here to derive a numeric 
representation by comparison of the string token keywords 
to their relative position in the tables, and derive a 
string index when the token is identified • The event 
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decoding takes place using a separate thread of execution 
dedicated to fielding incoming command and event 
messages. 

Command Encoder 

5 This component converts SCI calls to a text 

command message representation , and then sends them to 
the remote station. As with the event encoder, the exact 
text command message format is left to the system 
designer, and correspondingly, it should be entirely 

io universal for reasons said. String tables in the 

Linguistic Controller areas of the VCO are used to create 
text command messages whose format is variable depending 
on the SCI command encoded. The command encoding takes 
place using a separate thread of execution dedicated to 

15 fielding incoming command and event messages. 

Command Decoder 

This component redirects the text command portion 
of the shared messages to the local VCO terminal input 
port, where they are interpreted, and then used to 

20 generate calls to the local VCO's SCI, just as if they 
had been input from a local user at a terminal keyboard. 
This process is the inverse of the encoding process, and 
its success depends upon the consistency of the text 
command message format selected. The event decoding takes 

25 place using a separate thread of execution dedicated to 
fielding incoming command and event messages. 

Determining Capabilities 

Each VCO has associated with it independent 
parameter blocks for remote control parameters and remote 
30 monitoring parameters • There are separate parameter 

blocks each containing flags that indicate their current 
operating modes, and operating capabilities with regards 
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to attachment. The control and monitoring capabilities 
are stored as nonstandard capabilities in the local 
capabilities lists, and each station will know those of 
the other at the time of connection. Once attachment has 
s been established, it is the station that first requests a 
particular control or monitoring "context" that will able 
to assume that role. When a role is assumed, flags in the 
associated parameter blocks mark the state, and prohibit 
any further context changes till the stations are 
io detached, disconnected, or the change is initiated by the 
-controlling" or "monitoring" station. 

Remote Monitoring 

As a subset of a full remote control context, 
monitoring of a remote station requires only that the 
is "monitor" station receives a stream of the events queued 
by the "monitored" VCO. Upon connection, both stations 
are monitoring their own locally queued events; they are 
operating under a local monitoring context. If one 
station permits (indicates it is capable of) being 

20 monitored, the other can change its monitoring context, 
by setting its monitor mode flags to include the remote 
stations events, and therefore add the events from the 
other station to its own event queue, in addition to 
continuing to monitor its own event stream concurrently. 

25 Alternately, it can monitor only those events of the 

other station, or monitor any one of a group of stations 
in a conference, as they come into focus (though a 
virtual attachment must be established with each 
individual station prior) . Monitoring can occur bi- 

30 directionally at the same time; two stations may monitor 
each other concurrently. 
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Remote Control 

The assertion of control by one station, over 
another, proceeds similarly to the establishment of a 
monitoring context. In doing so, one station's 
capabilities indicate it will assume a slave operating 
context, while the other will be the master. Upon 
connection, both stations are controlling their own 
systems; they are operating under a peer control context, 
and have no ability to control the other. The master VCO 
initiates the transaction to reguest operational control 
of the other, and if consent is given by the other, it 
assumes the role of master, the other as its slave. The 
slave VCO now reacts to commands sent by the master, just 
as if the commands had been issued by its local client 
application. For remote control to occur, the master must 
also monitor the event stream of the remote VCO. With the 
ability to transparently send commands to a slave 
station, and transparently receive events from the 
station in response to those operations, the VCO that 
assumes the master control context becomes a fully 
operational virtualized representation of the slave 
station. And client applications that run on the master 
VCO are (practically speaking) virtual clients of the 
slave VCO. 



MULTIPOINT CALLS 

A number of recommendations serve to define 
standard designs, protocols, and terms used for 
audiovisual connectivity sessions that involve more than 
just a local and remote station, ITU-T Recommendation 
H.231 (see ITU-I Recommendation H.231, MULTIPOINT CONTROL 
UNITS FOR AUDIOVISUAL SYSTEMS USING DIGITAL CHANNELS UP 
TO 2 Mbits/s, 1994) describes such units and their 
various configurations. Attendant Recommendation H.243 
(see ITU-1 Recommendation H.243, PROCEDURE FOR 
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ESTABLISHING COMMUNICATION BETWEEN THREE OR MORE 
AUDIOVISUAL TERMINALS USING DIGITAL CHANNELS UP TO 2 
Mbits/s, 1994) describes the specific operations 
performed in a multipoint call environment, such as 
s adding, dropping, and viewing specific conferees from the 
conference. These recommendations serve as the impetus 
for the logically defined multipoint control operations 
incorporated into the VMCS server (VCO) architecture. At 
time of writing, there exist fewer than a half-dozen 
io widely available devices supporting a significant subset 
of the procedures outlined by the recommendations. 

VCO Multipoint control Operations 

Support for multipoint operations by the vco 
requires the use of a multipoint control unit (MCU) . 

15 These devices have a number of NIUs, referred to as 

ports, that allow many audiovisual connectivity stations 
to attach to them concurrently — the MCU serving 
primarily to bridge the signals from one station to that 
of many others, so as to enable a group to view an 

20 individual. A specialized algorithm determines which 

conferee, at any given time, is to be seen by the others. 
In most cases, the strength of the audio signal (voice 
presence) determines the individual that addresses the 
conference. A chairman is specified to direct the 

25 conference, and he possesses special privileges to 

administer its outplay; his responsibilities as chairman 
include the appropriate allocation of resources, the 
creation of conferences, and the configuration equipment 
as needed. 

30 The multipoint control operations supported by the 

VCO MultiCall SCI Member are shown below (see FIG. 30). 
Calls to this MultiCall member map to the PDI 
DevMultiConnect member, one that provides an actual 
physical implementation for them. To support the 
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operations, this PDI member will typically be constructed 
to issue vendor-specific commands to a MCU resident in 
the station, or cabled to it with some communications 
link- All of the major operations needed to directly 
5 control the mechanics of a conference, as its chairman, 
are included. Further discussions of these operations are 
provided in the source code (see section entitled VDI 
Header File in Appendix) . The CALLPARAM structure in the 
VCO has a number of flags and variables used to track and 
10 configure multipoint control operations. A series of 
flag values referred to as MULTI CALLS TATES provide 
detailed indications as to very specific states in both 
the local VCO, and the conference in which it is 
participating . 

15 VCO IMPLEMENTATION PROCEDURE 

The procedure to implement a VCO differs 
depending on whether the project is to create an initial 
server component, or to create a new component (from an 
existing one) that will work on a new multimedia 

20 connectivity sub-system. While primary (initial) VCO 
development requires considerable effort, secondary 
(subsequent) VCOs are comparatively minor projects in 
both time and resource requirements. The development of 
VCO clients can proceed concurrently with, and 

25 independently of, that of the server (s); the production 
of VCO Clients requires markedly less design and 
development expertise than is required to produce the 
VCOs themselves. 



VCO Implementation Sequence 

The following procedure is applied to primary VCO 
development. Secondary VCO development efforts (based on 
the same design) reuse almost all components, without 
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modification, thus steps 1, 3, 4, and 5 are not necessary 
to create them. 

1) Derive VCO Design 

Prefatory to development of a VCO, a detailed 
s design for a specific implementation must be 

derived from this disclosure of the VMCS 
Technology, in addition to describing the 
internal mechanism, this design provides the 
definitions of the external interfaces to 
10 client applications, and to other VCOs 

created to run on different types of host 
stations; these specifications should be 
preserved for all subsequent implementations 
to maintain interoperability across the 
is network. 

2) Establish Sub-system Operability 

It must first be determined if the 
connectivity sub-system and associated 
devices are operational. Any test procedures 
20 and test programs must be executed on a sub- 

system installed and configured exactly as 
specified by the particular VMCS server (VCO) 
design discussed in step 1. 

3) Develop Virtual Device Interface 

25 Source code development for the VDI includes 

creating all of the classes from which it is 
derived. The device- independent portion of 
the VCO is implemented as a distinct unit 
that can be built without any dependencies on 

30 an Y device-dependent, or vendor-specific 

components . 

4) Develop PDI Shell with Emulation Support 
Source code development of the PDI proceeds 
initially as an attempt to create a minimal 

35 implementation that will support emulation 
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for its pure virtual device control 
overrides. Calls for device support return 
"Not Implemented", or if the VDI has invoked 
emulation mode, they return an emulated 
response, as if a device was physically 
present. 

5) Debug VCO as Emulation Object 

Running in emulation mode, the VCO is 
debugged to verify the functionality of its 
device-independent portions. A small sample 
client application must be created to invoke 
SCI members for testing purposes. 

6) Develop PDI Physical Device Controls 

Once the VCO is fully operational and 
debugged under emulation, physical device 
control is added to the PDI by providing a 
software linkage of the pure virtual device 
control overrides with the connectivity sub- 
system and associated devices previous 
emulated in software. Media Control Objects 
are implemented, tested, and integrated into 
the device control system. 

7) Debug VCO as Live Device Control Component 
Running in the default device control mode, 
the VCO is debugged to verify the 
functionality of all of its components and 
features in a "live" connectivity 
environment. A sample client application must 
used, as in step 5, to invoke SCI members for 
testing purposes. 



DEPLOYMENT 

This section describes usage of the disclosed VMCS 
technology in an operational configuration. 
Consideration is given to the underlying theories of VMCS 
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operating principles, including discussions relating to 
the sequences of operations needed to manage various 
multimedia connectivity tasks encountered during vco 
connectivity sessions. In essence, the following section 
serves as an operations manual for the VMCS, focusing 
mostly on the services provided by the VCO. 

OPERATING PRIMCTP T.pg 
CONSTRUCTION , 

VCO construction is a process defined by C++ as a 
means to create a binary software object from a class 
definition. With the VCO, the client initiates a 
construction process that is in no way different from 
that of any other class, and the VCOPARAM data structure 
is initialized, along with other initialization tasks. 
Upon successful construction of the Virtual Connection 
Object, its principle data structures and capabilities 
are available for perusal. 

• Construction gives the client access to VCO 
internal data structures, use of basic 
device- independent services, and the results 
of a perfunctory examination of requisite 
supporting sub-components. 

• By the time VCO construction has completed, 
its dispatcher is running, and it has 
uploaded all configuration parameters from 
backing store. At this time, the notification 
mechanism is fully operational, and Notifier 
Objects can be created for use by the client. 

Following VCO construction, the VCO terminal 
input and output ports are active, and can be 
used by the client to send text messages to 
output devices, or to decode command input. 
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• Although the VCO may have successfully 
constructed, no drivers have been loaded, no 
devices have been accessed/ initialized, and 
there is no way for the client to know if the 

5 hardware necessary to run this VCO is 

actually installed ♦ 

DESTRUCTION 

VCO destruction is a process defined by C++ as a 
means to destroy a previously constructed binary software 
10 object. With the VCO, the client invokes a destruction 
process that is in no way different from that of any 
other class. During the process of VCO destruction... 

• If the VCO is connected, a disconnect is 
issued — the VCO waits until the disconnect 

15 completes — and all associated VCO 

components and drivers are unloaded. 

• The VCO dispatcher is halted, and any 
Notifier Objects are deleted, thus 
Notification Receiver Objects in the client 

20 will no longer receive inf ormation. 

• The terminal, and all other VCO services, are 
no longer available for client use, since the 
VCO does not exist following destruction. 



NOTIFICATION 

Once a client constructs a VCO, it can create a 
number of Notification objects, the maximum of which is 
determined by the system designer. Notification 
indications are sent to the client immediately following 
construction, should any triggering events should occur. 

• The NewNotifier command enables the creation 
of a Notifier Object, returning the handle to 
one just created as specified. When the 
Notifier Object is created, it is intimately 
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associated with one particular Notification 
Receiver Member contained within one 
particular Notifier Receiver Object, neither 
of which can be changed; a new Notifier 
Object must be created to direct notification 
to a new object-member combination. 
The DeleteNotifier command can be used to 
delete Notifier Objects, the handle of the 
Notifier Object being used to identify the 
instance to delete. 

The EnableNotifier command can be used to 
enable or disable the specified Notifier 
Object. Each Notifier Object can be disabled 
to stop the VCO notification process to that 
particular Notifier. When enabled and 
actively receiving notifications, a call to 
the client's Notification Receiver Object (by 
the Notifier Object) occurs to prosecute 
indication of the occurrence of an event, 
during which time, it cannot be reentered by 
another such call until it returns from 
processing that event currently in play. 
The SetNotifierTriggers command allows the 
client to change the set of events that cause 
the Notifier Object to trigger; that is, 
invoke the Notifier Object to deliver 
information to a specific member function of 
a specific class object, indicating that a 
particular VCO event has taken place. 
The TriggerNotif iers command can be used to 
trigger one particular Notifier Object, 
unconditionally, or to present an event to 
the triggering mechanism, allowing it to 
trigger all Notifier Objects for the VCO that 
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contain that specific event in their 
triggering profile. 

• Notifier Objects cannot be created or deleted 
while processing the notification of an 

5 event, because the internal list of Notifier 

Objects is locked. However, the triggering 
profile for the Notifier Object can always be 
modified. 

CONFIGURATION/SYSTEM SETUP 

10 There are two distinct services available to VMCS 

system users for configuration/ setup. The first is the 
ability to maintain a VCO initialization file that stores 
a text record describing all of the startup defaults for 
major categories of VCO settings, including a description 

15 of its network service, standard terminal output device, 
local station identity, dispatcher rate, device and 
connection time-outs, conference profile, and other 
default settings. The second is the ability to invoke 
dialog boxes containing detailed configuration/ system 

20 setup utilities that are provided for each of the four 
possible media types (audio/ video/ image/data) that are 
potentially handled by the VCO. 

• The initialization file is read at VCO 
construction time, and its user-readable text 

25 arguments are converted to an internal binary 

format stored in the VCO, accessible as a 
data structure to VCO clients. 

• The SetConf ig command allows clients to write 
a new configuration structure to the internal 

30 VCO configuration structure, and at the same 

time activate the new settings. 

• The Ref reshConf ig command allows clients to 
upload the VCO's internal configuration from 
its default initialization file, and at the 



- 142 - 

same time activate the new settings. 
Alternately, the command can be used to 
upload the internal configuration stored in 
the initialization file into a client 
configuration record, leaving that of the VCO 
configuration record unmolested. 
The StoreConfig command enables clients to 
store a configuration record directly in the 
default VCO initialization file, overwriting 
the existing configuration, or alternately, 
it enables clients to similarly store a 
configuration record held privately by the 
client. In either case, the data elements in 
the configuration record are converted to 
user-readable text arguments prior to being 
stored in the initialization file. 
Integral configuration utility screens enable 
end users to adjust relatively minor vendor- 
specific device driver and operating specific 
system parameters that do not map well to the 
generalized, device- independent controls 
offered by the VDI and associated media 
control device control settings. 
The VMCS concept intends these adjustments to 
be limited to those settings that are usually 
set once during initial system installation, 
and subsequently left mostly alone; they are 
settings that tune and enhance the operation 
of the standard VCO device control 
operations, and are not intended to duplicate 
or replace them. 

The strategy behind these utility screens is 
identical to that used by advanced 
microcomputer operating systems, employing 
graphical user interfaces, whose printer 
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device driver designs require an integral 
"setup dialog" to enable the user to 
configure the specialized hardware features 
of a target printer device , prior to sending 
the job to the print queue* 
As specified by the system design, 
configuration and setup parameters adjusted 
in these utility screens are used to set the 
device default settings that are later 
manipulated through standard SCI calls to the 
device control sub-system. Moreover, vendor- 
specific configuration files are modified 
here via links to their particular private 
software component configuration scheme. 
The SetupAudioDevices command invokes the 
audio setup utility, which provides 
adjustments for microphone input sensitivity, 
frequency equalization, output gain, 
specialized physical input/output port 
selection, noise filtering, and recording 
options. 

The SetupVideoDevices command invokes the 
video setup utility, which provides camera 
adjustments such as white balance, access to 
test modes, NTSC/PAL mode selection, and 
focusing mode selection. Additional 
adjustments for video display include those 
that affect color, tint, hue, brightness, 
horizontal alignment and vertical alignment. 
The SetupImageDevices command invokes the 
image setup utility, which includes output 
settings for any hardcopy display/printer 
device, or video display adjustments for 
factors similar to those in the video setup. 
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Input settings for imaging devices typically 
relate to form size and ambient lighting. 
• The SetupDataDevices command invokes the data 
setup utility, which is more nebulous in its 
5 specific format, and whose settings may range 

from communications port settings to disk 
drive specifications for backing store. The 
VMCS make no presumptions as to the ultimate 
use of data streams, thus the derived VMCS 
10 design must specify the data setup utility. 

Typically, a VCO that directs a data stream 
to/ from a communications port will maintain 
settings for baud rate, parity, stop bits, 
and other asynchronous data transmission 
15 settings. 



TERMINAL SERVICE 

The VCO terminal service provides an input and 
output port. The terminal output port functions as a 
standard output device that displays character stream 

20 data written to it, while the terminal input port accepts 
character stream data written to it, and interprets it as 
VCO text commands. Character stream data takes the form 
of null-terminated ASCII strings, referred to as text 
messages. The null character is used to denote the end of 

25 the message. Format dictates VCO text command strings 
terminate with a carriage return, and intervening nulls 
that terminate command (sub-strings) are ignored by the 
decoder . 

• Text messages sent to the terminal output 

port may be written, concurrently by the VCO, 
to more than one physical output device, 
following each client text output operation. 
Physical output devices configured to be 
written when text messages are sent to the 
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VCO terminal output port, are referred to as 
attached (to the output port) . Resultantly, 
clients sending text messages to the default 
VCO terminal output port will find that the 
same text message has been duly written to 
all output devices attached to the terminal 
output port. 

Text messages sent to the terminal input port 
are parsed into string command and argument 
tokens, and interpreted by the VCO as 
representations of SCI commands. Once a text 
command has been fully decoded, it is used to 
affect SCI member functions, thereby 
providing a scripted control mechanism to any 
VCO client; scripts can be generated by the 
local client, read from script file, 
transmitted from a remote client across a 
connection, or entered directly from a 
terminal. 

The terminal service is available immediately 
following construction. A default output 
device is identified in the configuration 
stored in the VCO initialization file, and 
attached to the terminal output port. 
A range of standard output device types can 
be added or removed from the list of output 
devices attached to the output port. All 
output devices are written with every text 
message that is sent to the terminal output 
port. 

The ToTerminal command is used to send an 
optionally formatted text message to the VCO 
terminal output port. The command functions 
similarly to "print" statements used by 
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various programming languages that send text 
to a standard output device. 
• The FromTerminal command is used to send an 

optionally formatted text command (VCO script 
5 command) to the VCO terminal input port. NOTE 

THAT the terminal input port cannot be read 
for input by the client, as the term input 
refers to the provision of input data to the 
VCO from the client. The client is the source 
10 of the character stream. Since the VCO has no 

reason to request commands from the client 
(only the client can initiate the issuance of 
commands) the onus is on the client to send 
those commands to a mutually agreed-upon 
15 place where the VCO can receive them, and in 

so doing, invoke the VCO to decode them. 
Reiterated more plainly, the client "stuffs" 
script commands in a buffer, and calls the 
VCO to interpret them. 
20 • A Notifier Object may be created and utilized 

as a terminal output device. When the 
Notifier Object is attached to the terminal 
output port, it may be triggered by any VCO 
(or client) text output sent to the terminal 
25 output port, thereupon the Notifier Object is 

explicitly triggered so as to make the 
client's Notification Receiver Object the 
recipient of every text message sent to the 
terminal. This mechanism allows any client to 
direct all text message output to a client's 
text processing routine. 

NETWORK SESSION 

Establishing a network session is accomplished by 
invoking a sequence of SCI members. Construction and 
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destruction of the VCO frame the connectivity session in 
that a VCO is usually selected and constructed just prior 
to connecting to a remote station, and is subsequently 
destructed immediately following the termination of the 
5 connection to it, therein freeing all system resources 
erstwhile allocated to the maintenance of that 
association. The process of associating two stations 
across the network, for the purpose of exchanging audio, 
video, image, and binary information between them, is 
io advanced by a sequence of VCO operations next described: 

• The Open command initializes the encapsulated 
multimedia connectivity sub-system, loading 
and starting all supporting vendor-specific 
software components. Until the "open" is 
15 performed, only non-device related VCO 

services are active. All devices are started 
and tested to determine that they are fully 
operational. All available signals are 
represented in newly created Media Control 
Objects, and then are opened for use. The 
entire sub-system, including all hardware and 
software components, is set to default 
startup settings, and the network connection 
is verified. If the open is successful, a 
connection can be established at any time, 
and all local devices are accessible to the 
client, to be controlled by the user. 
Incoming calls from a remote station may be 
handled following a successful open. 
• The Call command initiates a call to a remote 
station. In the preferred VMCS embodiment, 
the network is the ISDN (telephone system) 
and the "call" operation results in a direct 
dialing of the number of the remote stations 
35 line(s) . Just as with a standard telephone, 
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35 



the visual telephone service provided by the 
VMCS requires no further action by the 
client, and a simple result is returned. A 
successful connection process results in the 
execution of an internal VCO process to 
establish a series of baseline operating 
modalities for the type of session 
established. For the visual telephone, a 
video window is displayed showing the far 
end, remote station audio is audible, and 
both local video and local audio are sent to 
the remote station. Image and binary data 
facilities are initialized as idle, and 
pathways await client operations to exchange 
information. In short, the "call- operation 
of the VCO's visual telephone system works in 
an identically analogous fashion to making a 
"call" with a standard analog telephone: 
dial, connect, then concurrently exchange 
information bi-directionally, without delay. 
The Multicall command enables the initiation 
of a number of complex multipoint control 
operations (see FIG . 30). if the local 
station is the conference chairman, the VCO 
client can add and remove conferees from the 
conference, among other administrative 
functions, all of which require the ability 
to control a multipoint control unit (in some 
direct or indirect fashion according to the 
actual physical implementation of the VCO 
service) . other multipoint operations include 
various query and broadcast operations that 
may or may not require an advanced level of 
MCU control. The client can query any of 
these operations to determine if they are 
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currently supported by the session in 
progress. The client can determine if the VCO 
implementation supports the operations at all 
by examining the VCO capabilities list, which 
includes multipoint control capabilities that 
are proprietary to VMCS technology. 

• The Hangup command enables the client to drop 
one, or more (all) lines used for the current 
call. Similar to the "call" operation, the 
"Hangup" operation of the VCO's visual 
telephone system works (by default) in an 
identically analogous fashion to the "Hang- 
up 11 of a standard analog telephone: end the 
call without delay. 

• The Close command shuts down all devices in 
the multimedia connectivity sub-system, and 
unloads all vendor-specific software 
components. All client access to device 
control services is no longer available, and 
Media Control Objects are all destructed. 
Neither incoming, nor outgoing calls may be 
handled, and only the non-device related 
services remain active. 

MEDIA DEVICE CONTROL 

Device control is available to the client by the 
manipulation of Media Control Objects via calls to the 
MediaControl SCI member. The VCOPARAM structure contains 
a list of the names of all available Media Control 
Objects active in the system. This list will be empty if 
the VCO has not been opened first, as the list of Media 
Control Objects reflects the signals available for 
manipulation by the client. A list of the handles to 
these Media Control Objects is also available, and 
information about them may be obtained using the 
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appropriate SCI member function. Principles governing the 
control of the devices in the encapsulated sub-system, 
and their associated operations, are shown below: 

• There are four signal types (audio, video, 
image, data) and four signal directions (to 
remote, from remote, to device, from device) 
from which sixteen Media Control Object type 
permutations are derived. These are the 
sixteen default Media Control Object types 
that may be addressed by type in operations 
(see FIG. 7A) . 

• Following successful completion of a VCO open 
command, any available signals in the VCO are 
represented as Media Control Objects, 
automatically opened for use, and enabled. 
They are not switched on initially, but must 
explicitly be turned on by a client command 
or by connection to a remote station. 

• The Mediacontrol command enables clients to 
change the settings for any active (existing 
and enabled) Media Control Objects assigned 
to be one of the sixteen default types. 
Additionally, switching of signals (in the 
form of plugging together source and 
destination Media Control Objects) , creating 
composite signals from multiple input 
signals, and a host of related functions can 
also be accomplished with this command (see 
section entitled VDI Header File in 
Appendix) . 

• The SetDefaultMco command can be used to 

assign a non-default Media Control Object as 
a default Media Control Object, if it is the 
same type as the one it is replacing. 
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The GetMcoHandle command can be used to 
retrieve the handle to an Media Control 
Object from its name label or object type. 
GetMcoLabel is a command that allows the name 
label for the Media Control Object to be 
determined from its handle. 
The GetMcoParam command can be used to 
retrieve the internal parameters and settings 
for a specified Media Control Object , and 
thus it can be used to determine the 
operational states and settings of the signal 
represented by the Media Control Object , as 
well as the device (if any) that is the 
source or destination of that signal. 

15 BINARY DATA OBJECT EXCHANGE 

Data objects may be exchanged with single 
operations, between stations that are both running a 
VMCS; each of which fully understands the data formats 
and "transport layer" protocols of the other end. For 

20 now, such issues are left to resolution by the system 
developer who must determine the exact protocol used to 
transfer the VCO* s data objects as described herein. 
Though lacking in international standardization, 
manipulation of binary data objects is operationally well 

25 defined and described to client applications by the VMCS 
(The Software Control Interface and the logical 
manipulation of which is clearly implemented in the 
■session layer" residing in the VDI) . Fortuitously, the 
ITU is currently working on Recommendation T.120 (Data 

30 Conferencing) to enable standards-based exchange of 
binary data objects. A case could be made for the 
utilization of this VMCS model for all connectivity 
software systems on the sole basis of its ability to 
insulate applications from the ongoing T.120 
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specification, and the complexity of its implementations. 
As of this writing, T.120 remains incompletely specified, 
only partially implemented by any real products, and even 
less well understood by system developers. It is expected 
s that T.120 will eventually provide the "language- 
necessary for the vco to conduct its -binary data object 
exchanges" below the " session layer" , in an entirely 
standards-based fashion. 

If the remote station is not running a VMCS, 

10 simple data buffers and cursor positions may be sent 

according to existing procedures for information sharing 
in H.320, but support to transfer entire binary and/or 
text files may not be available, if it is determined that 
the remote station connectivity sub-system is a 

15 compatible VCO (using the isVCO command) , then any data 
object can be transferred, otherwise, if the data object 
to be transferred is a file, the remote station will be 
unable to respond to the VMCS proprietary file transfer 
protocol used on the data channel. Support for the 

20 exchange of cursor positions, facsimiles, still pictures 
(images) and raw data buffers is supported by most H.320 
compliant stations, and thus possible between a VMCS and 
any remote station to which it may be connected. The 
mechanics of exchanging data objects between stations are 

25 discussed below: 

• The Transf erBuf fer command enables a client 
to send a buffer of binary data through the 
data channel (or multiplexed data channel 
using an allocated portion of its total 

30 bandwidth) , to the remote host. This command 

can also be used to determine if the data 
channel to the remote station is available. 

• The Transf erObject command enables a client 
to send or retrieve a specified data object 
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through the data channel, or multiplexed data 
channel. 

The transfer operations specify a Media 
Control Object whose data signal is used to 
transport the data. If the remote station is 
running a VMCS, the direction of Media 
Control Objects signal determines whether the 
transfer operation sends local data to remote 
station (data to remote) or is a request to 
retrieve data from the remote station (data 
from remote) . 

The Media Control Object used for the 
transfer contains data structures and 
variables that describe the actual status of 
the transfer. 



SYSTEM INFORMATION 

Access to system information is highly restricted, 
from the view of the client, and is only available 
through SCI members. These members handle a wide variety 
of VCO states and parameters, and provide that 
information to the client in divers formats: 

• A number of VCO states and conditions are 
reported by SCI members returning boolean 
results. These boolean test members allow 
clients to determine if the VCO is ready to 
make a call, if a call is currently being 
setup, if a call is connected, if a 
multipoint call is in progress, if the remote 
station is a VCO (running a VMCS) , or if the 
current VCO exists in more than one instance. 

• References to copies of data structures, 
stored internally in the VCO, are returned 
for those specific categories of information 
relating to devices, configuration, call, 
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protocol, control, and monitoring parameters 
One member returns a reference to a copy of 
the entire vco system information data 
structure. 

5 • The internal data structure of a Media 

Control Object can be accessed in a way 
similar to other data structure, with the 
client specifying the default Media Control 
° bjeCt type ' or a handle to one. Also, the 
handle for a Media Control Object can be 
obtained from a Media Control Object label or 
the Media Control Object' s type. 
Text names for most enumerations, constants, 
and SyStem ob :>*cts can be retrieved from the 
VCO using any one of a number of members 
designed to return labels to them. 

PROTOCOL MANAGEMENT 

The H.320 protocol defines the basic operational 
structure of the VCO's multimedia connectivity services 
20 and from the standpoint of the client, is mostly 

transparent to its functionality. An exception lies in 

capaIilitr PPOrt . f ° r manipUlatio " ot device modes and 
capabilities; it is useful for the client to affect the 

25 ZllZl T bil±ty 1±St ' ^ WG11 35 ^ ^ — *~ -es 
clI!T ^ M ° reOVer ' SUCh — ^lows more Knowledgeable 
clients to perform advanced, or less well supported 
operations at a low-level. 

A data structure in the vco, referred to as 
PROTOCOLPARAM , provides the client with 
lnfornation a bout the H.221 multimedia 
connectivity protocol. A full accounting as 
to the progressions of which, is provisioned 
by this useful data structure, specifically 
with regards to current and pending device 
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modes for audio , video, data, and 
miscellaneous operations. 

• The SetConfProf ile command enables the client 
to specify a conference profile that 
describes a preferred set of audio, video, 
and data modalities (relative to the 
available bandwidth of the connection) that 
define the overall quality of the 
connectivity session. 

• The SetModes command enables the client to 
specify one, or more, H.221 device modes by 
presenting them to the connectivity sub- 
system. This command is used in conjunction 
with the VerifyBandwidth command to determine 
if there is sufficient bandwidth available in 
the connection to support a specified set of 
audio and data modes, while retaining the 
current video mode. 

• The SendCaps command enables the client to 
transmit its entire H.221 capability list to 
the remote station. 

• The SetDeviceTimeout enables the client to 
specify the number of milliseconds the 
Network Interface Unit should wait for a 

25 response from a network request before timing 

out, whereas the SetConnectionTimeout enables 
the client to specify the number of 
milliseconds the system should wait for a 
connection to a remote station to complete 

30 prior to timing out. 

VCO CONTROL OPERATIONS 

A large group of operations enables the client 
application to adjust, control, and invoke special 
features of the VCO. Some of these operations enable the 
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manipulation of internal VCO settings that are typically 
left to their default settings for most sessions. A 
number of commands are used by a client to attach to a 
remote VCO for the purposes of remote control and/or 
s remote monitoring of it. 

• The EnableVco command is used by the client 
to alter the state of the VCO's "enable" 
flag, a task usually reserved for recovery 
from an exception that previously disabled 
10 Lt ' The SetVcoExceptMode is used to set the 

exact modality used by the VCO to handle 
exceptions. 

• The SetVcoTraceMode command is used to 
instruct the VCO as to exactly which 
ib operations and components should be 

configured to direct trace information to the 
VCO terminal output port. 

The EnableMultiCallOps command is a simple 
switch that is used to select the client* s 
!0 accessibility to the multipoint control 

operations. To disable these operations 
causes them to return "disabled" to the 
caller. 

• The EnableDispatcher command is used by 
s clients to pause the dispatching of events 

from the VCO event queue. This operation is 
used when the client wishes to "idle" the 
VCO, while allowing underlying devices to 
function as best as they may. The related 
command SetDispatcherRate enables the client 
to change that rate at which events are 
dispatched from the VCO event queue, a task 
usually performed when a faster or slower 
event stream is required by the client 
application; faster dispatching rates allow 
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the client to operate at speeds closer to 
those of the encapsulated multimedia 
connectivity sub-system. 

The UpdateCapsList command is used by the 
client to add or remove a device capability 
to the VCO device capability list, a version 
of which is transmitted to the remote station 
during the connection process. A related 
command, UpdateModeCapsXRef , allows the 
client to add or remove a mode-capability 
cross-reference record that is used when the 
VCO attempts to establish common operating 
modes with its remote station peer. 
The EmuControl command enables the client to 
access an internal VCO emulation facility. 
Features include enabling/disabling the VCO 
device emulation mode, and invoking 
predefined emulation sequences. 
The AttachToRemote command is used by the 
client to provoke the VCO to attach to its 
remote station peer, if that peer is a VCO 
(running a VMCS) . The DetachFromRemote 
command eliminates any attachment between 
interconnected VCO peer stations- When the 
VCO is attached, the SetVcoControlMode 
command is used to select the master, slave, 
or peer modality of operation for the local 
station, with respect to the remote station. 
The SetVCOMonitorMode command enables the 
client to select the event stream for the VCO 
to process. Events from the local station, an 
attached station, a group of stations, or 
some combination of station are directed into 
its event queue for subsequent dispatching. 
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The SetStationLabel command is used to assig 
a text label to the local station so that it 
may be referenced (locally or by a remote 
station) by that name. 



5 SAMPLE CLIENT APPLICATION 

Source code in this disclosure (see section 
entitled Sample VCO Client Application in Appendix) 
illustrates the use of VCO services by a multithreaded, 
event-driven VCO Client application. This simple program 

10 does not utilize a graphical user interface, but directs 
its output to the standard output console. The program 
examines a VCO's capabilities to determine if it supports 
required audio, video, and data modes, and opens a 
connectivity session if it does. Source code is also 

15 provided for the many header files used by both the VCO 
Clients and the VCO itself. 

The invention is meant to cover all of the above- 
mentioned alternative approaches as well as others not 
specifically mentioned. The above-mentioned embodiments 
20 and others are within the following claims. 
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3500 



3510 



SOURCE CODE 
VDI HEADER FILE 



VIRTUAL DEVICE INTERFACE HEADER FILE 
WW for 

VIKTUAUZED MULTIMEDIA CONNECTION SYSTEMS 

ABSTRACT 

3495 This source module contains defuuooru for the principle software enumerations, constants, daa structures, tod member functions 
thai comprise the Virtual Device interface <VD!> software component of a Virtual Connection Object (VCO). These items must be 
incorporated into both the client and server e mines of any VMCS implementation, m some form of computer language 
repre senxaoon. The device interface components are internal (nonpublic) to me VCO, and are of the pure virtual cype. All other 
member funcoons. scrucAires. and coassano shown below arc used by every VCO to enable soucoircd acces s to their encapsulated 
mulamedia connectivity sub-system, and by VCO Clients desirous of structured access to a devee- independent rcpresemaooa of the 
same. These member funcoons and member daa objects are collecnvely referred to as tfte Software Controt interface-, tney arc the 
same for every VCO tmpiemeraaoon. thus enabling crcaoon of device -independent connecovrry ippiicaoons that exploit their 
services. 

3505 '.SOURCE FILE. VDI.H) 

PROGRAMMING NOTES 

t . This module conn ins only C+ + source cod* and structured comment! using the * ft ' noaooo to denote comments (us addition 
to the standard C comment notation using * /* •/ *). 



2. The term unknown refers to a value, condition, or re queste d o pennon chat can not be idenofied: that u the usage of this word 
connotes a patently errant condition. 



3. The term unexpected refers to a value, condition, or requested operaoon that is tdennftabie. but is inappropriate given the current 
3515 set of preconditions: that is the usage of this word connotes inappropriate nets of conceal. 

4. The term excepaon refers to an occurrence of a seventy that warrants abandonment of the cormecnviry sub-system (a fatal error): 
such an occurrence connotes significant desrabduaoon of the VCO has occurred and further usage risks a system crash 

3520 5. The term blocking describes calls that wan for the requested operation to fully complete, the return value of which indicates its 
results. This modality of operation is the default for all calls. If there is a " JsBtocaing' argument to me call, and it is set to 0 
(false), then the call returns immediately without watting for the operation to complete, typically returning 'pending * if die request 
is valid. Indication as to ine result of this operaoon comes from die insertion of a desenpove event into die VCO event queue upon 
its completion. 

3525 

6. All character pointers (char*) point to nuil-termtnated ASCII strings of a length less than 256 characters, including me ouil. 

7. The term tabei refers to a stnng as defined in <6.) above, except that it may not contain spaces and its length it Less than J 2 
characters, including the null. 

3530 

ARGUMENT SYNTAX 
for 

VIRTUAL CONNECTION OBJECT EVENTS 

3535 Nooftcaooo of the occurrence of a standard Virtual Connection Object event u initiated when a noafkaoon object m the host VCO 
'triggers*, and tubsequemiv calls a specific event handling hincuon rending in a designated Nonfxcanon Receiver Object (NRO). 
that u. a software object mat contains member funcoons implemented specifically to respond appropriately to that type of system 



3540 EVENT IDENTIFIER PARAMETER 1 PARAMETER 2 



NuHEvent Don t care Don't care 

NtwEmuSlaut True if emulation enabled Don't care 

NewEeosjOp < EMULAHONOP > Don t care 

3545 NtwRcfCouxtf Previous reference count New reference count 

NewDevtcftStat* < DEVIC ESTATE > Device mdea 

NewMcoForua < MCOTYPE > Per to media crd obj Ubcl 

Ntw Local Cap* Previous number capabilities New number capabilities 
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3550 



3555 



3560 



3565 



3570 



3575 



NewReoooteCaps 

Ne«RrrMod« 

NewXnuMode 

Ne«ReiModc 

New A ttdioSttttef 

NewVWeoSetung 

New loiageSct ting 

Ne w DmtfcSetting 

NcwCaUState 

NewUoc LStaua 

N«wLk>«2St*te 

NewDfscStarus 

NewM itttrCa ilSuta 

NcwMubiCallOp 

NewDutaJCfcrScate 

NewRcvBuiTer 

NewXmlBuiler 

NewRerObjeet 

NewXauObject 

NewVeoSia*e 

NewCuraorPoe 

Ne^Tf i -rrp^n pift 

NewTertnOutput 

NewResuUCodc 



< 
< 
< 
< 
< 



Previous rounder capabilities 

< BASCODE > 
BASCODE > 
BASCODE > 
MCO.SETTINC > 
MCO SETTING > 

: MCO SETTING > 

< MCO SETTING > 

< C ALLSTATE > 

< UN ESTATE > 

< UN ESTATE > 

< CONFpRO FILE > 

< RES ULTCODE > 

< MULTICALLSTATE > 

< MULT7CALL0P > 

< XFER5TATE > 
Number of byte* received 
Number of by tea transmsxed 

< MCO XFEROBJ > 

< MCO XFEROBJ > 

< VCOSTATE > 
High-word u X. low-word is Y 
Number of bytes transmuted 
Number of bytes 

tfartsraiBBd 

< RESULTCOOE > 



New number capabilities 
Don't care 
Don e care 
Don t care 

Parameter for setting 

Parameter for setxmg 

Parameter for scmng 

Parameter for semng 

Don t care 

Don t care 

Don t care 

Don t care 

Don't care 

Don't care 

Don t care 

Pn- to media Ctrl obj label 
Ptr co media ctrt obj label 
Ptr to media coi obj label 
PtrtoXferObfcct 
Pit to XferObject 
Don t care 

True if relieve to previous 
Ptr to message suing 
Ptr to message senng 
Pd* to invoking cmd strong 



35«0 



3585 



3590 



W>dcf 



unsigned 
unsigned 
unsigned 
const 



char 
ini 
long 

DWORD 
DWORD 
DWORD 
DWORD 



BYTE: 
WORD: 
DWORD: 
BASCODE; 
EVE NT: 
HNOT1T1ER: 
HMCO. 



" «-bic unsigned value < standard octet) 
" 16-btt unsigned value 
;/ 32-bit unsigned value 

// 32-bu unsigned H 221 bit-rate allocanon „gnaJ 
/ 32-b* standard VCO event aienafier type 
/ 32-bu handle used to reference tignal objects 
// 32-bn handle used co reference med» cTo^ecu 



consxant rypc 



:^S^ ATON DEPENDEKT C ^ D ^HD ELSEWHERE 



// Base class for ail transfer ob^ci descriptors 



22 BrT STANDARD VIRTUAL CONNECTOn'obJECT Ev"e>^ 



IDENTIFIERS 



3595 



3600 



3605 



3610 



36(5 



EV»fT-Ntns£vent 
EVENT NewEantfStKe 
EVENT NewEmuOp 
EVENT NewReiCoum 
EVENT NcwOeviccSuu 
EVENT NtwMrofecus 
EVENT NewLocaiCmpa 
EVENT NewRemoteCapa 
EVENT NewRevMode 
EVENT NewXmxMode 
EVENT NewRejMede 
EVENT NewAudioSetti&g 
EVENT NewVldeoSctting 
EVENT NewlmageSettlng 
EVENT NewDatnSettiaf 
EVENT NewCaUState 
EVENT NewUnelSut, 
EVENT NewUnelStatt 
EVENT NewCoeuTrolUe 
EVENT NewDiacSusua 
EVENT NewMultlCaOSiate 
EVENT NtwMulUCaflOp 



- 0*00000000; // NO-OP to event processor 

- OaOOOOOOOl: // New VCO etnulanon state 
' " N ~ operaoon 

- 0x00000004 // New VCO reference count 

- OrOOOOOOOa // New media control device 



I %2SSSS2£ " NeW Cttmnf ' Ctrl Object has been set 

r^2S ; " NCW **« "« -viable 

I " N ~ remote capability Its. available 

n*2E£?2 ; " NCW ««• *« » renxTttacon 
"n!££^" Ne "^n>ode set by local staooT 
" EE*** " Ao «** » «« dev.ee mode re,ccte7 
" ? t ?^ 00: " New audio obicct 

" " New «— « for rnooon ^eo cb^ct 

" S : " New Mmn « imaging object 

- I*™*™**' " New .ctnng for bitse^un octect 
• 0x00004000: // New call state 

- OaOOOOaoOO: // New line I state 

- 0x00010000: // New line 2 sate 

" " N€W Pmfde for call 

" O^SSnS : " NCW dUCOnne « "om network 

- 0 tO0O«0O0O: // New mulupoini call tute 

- OtOO.OOOOO: // New mul0poini ulI opcnuon complci£ 
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3625 



EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 



NewDataXferStatc 

N«v*Rcv Buffer 

NewXmtBu/Ter 

NewRcrObjed 

NcwXmObjMi 

NewVeoStaca 

NcwCtirierPos 

NcwTcrmiofmt 

NcwTemOvipui 

NewRexuitCod* 



0x00200000: 
0x00400000: 
0x00800000: 
> 0x01000000: 
0x07000000: 



0x08000000: 
' 0x10000000: 
0x20000000: 
0x40000000: 
0x80000000: 



// New data nrafcr race 

// New daa buffer receive complete 

// New daa buffer transmission compiete 

II New data object reccrve compiete 

// New daa object transmission complete 

// New global VCO rate 

// New cursor postoon from remote taoon 

// New tit message to VCO (to VCO terminal input port) 

// New text menage from VCO (to VCO terminal output pom 

// New result code from interpreted VCO command 

II Reserved tmptemcnation-dcpendent event 



3630 



NUMERICAL CONSTANTS 



i Maa&eriees - 2: 

const art MexObjForDe* - 3: 

const int M&xMcoTrp* - 16: 

3633 const ira VUxXRef - 3: 

const int MaxModcs - 100: 

const inz MaxCap* - 100; 

const on MuLba - 2: 



// Max number cncapsuUted devices 

// Max number medu coi objects per device 

// Max number of medu ctrl object types 

// Max numoer mode -cap rc(s per record 

II Max number tool H.221 device modes 

// Max numoer tocaj H.221 device capabilities 

// Max lines manageable by oil controller 



3640 



ENUMERATED CONSTANTS 



// VIRTUAL CONNECT OBJECT GLOBAL OPERATIONAL STATES 
3643 rypedef emus { 
VcoOpcn. 
VooQosod. 
VcoFaikd. 
VcoDismbiod. 
3630 VcoStateEod 
J VCOSTATE; 



// VCO is inioaJized and openoonai for calling 
II VCO is not opermoooaJ: no calls possible 
// VCO experienced failure, but is sunoi operational 
// VCO has been disabled and is no longer openoonai 



// EXCEPTION HANDLING MODALITY FLAGS 
rypedef eoum { 

3633 ExccptModeDebui * OxOl. 

ExceptModeUser » 0x02. 

ExccptModeTerm • 0x04. 

ExccptModeNouiier - 0x08. 

ExceptModeAbon - 0x10 
3660 } EXCEFTMODE: 



// True enables ouqxit debug in/o in msg box for exception 
// True enables output "user" info in msg box for exception 
// True enables sending exception info to terminal devices 
// True enables reporting of excepaon by triggering noaiicr 
// True enables abort of ops. and disables VCO on exception 



// TRACE OUTPUT MODALITY FLAGS 
rypedef enum ( 

TraceModc Device - 0x01. 

3665 TraceM ode Nobfter - 0x02. 

TraceModeMCO - Ox04. 

TraceModeCaO - Ox08. 

TraccModeUne - 0x10. 

TraceModeProtD - 0x20 
3670 } TRACEMODE: 



// True enables all low-level device trace output 

// True enables noaficaoon e vera trace ounsut 

// True enables media cm object rxacc output 

'/ True enables high-level call corurol trace output 

// True enables k>w4evei call and line state trace output 

// True enable all protocol trace output 



If VCO CONTROL MODALITY FLAGS 
rypedef cntmt ( 

CtrlModePecr - 0x01. 

3673 CtrtMode Master - 0x02. 

CorlModeSlavc - 0x04. 

) CONTROLMODE; 



// True sets local direct local access possible 

// True sets local as master to conrrol remote VCO 

II True sets local as slave to remote VCO 
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36*0 



3643 



3690 



3695 



3700 



3703 



3710 



3715 



3720 



3723 



" VCO MONITOR MODALCTY FlAGS 

typcdcf enum ( 
MonModcLocaJ - 0x01. 

MonModeRcmoce • 0iO2* 

MonModcAmy « 0x04 

J MONTTORMODE: 



n Truc *«« monnonng to include local station 

ft True tea motutonng to include remote uiooa 

11 Tnje K « momtpnnf amy of sooom m con/eiroce 



OUn,m " DEV,CES F ° R *™HMENT TO VCO TERMINAL OUTPUT PORT 



TcrmOOtvNooftcr - 0x01. 

TerroODevFife . 0x02. 

TcrmOOev Scrum m 0x04. 

TermODevMCO . rjxOS 
) TERMODEV: 

// VCO EMULATION OPERATIONS 
rypedef cnum { 

Diix&eCxllEmuModc . 

EnxbleCxJIEmuModc . 

SetCallDstSooon. 

SecCtUDuMcu. 

Fi r ep o on . 

Unci Disc. 

LineXDtxc. 

RandomLinetDisc. 

RxndomlaneiOiic. 

Una I Ring. 

UneiRmg, 

UnelRjngbxck. 

Line2Ringback. 

UnelCoonect. 

LineJConncci 

OncLtnelncoming . 

TwnLinclncoottpg. 
OneLancOutfouuj. 
TwoUrjeOutfotng. 
OrteUneOutgotngflusy. 
T woLineOutg otngBusy . 
OncLuirOuixouvtRc;. 
TwoUncOutgouujRej. 
TwoUneFuliCairrhcnDiicRqM. 
OneUneAudioOnly. 
OneUncAudioVideo. 
TwoUneAudio Video. 
TwoUneAudioVideoOxa. 
CxUEuttiUoonOpEod 
) EMULATIONOP: 



■ ( w/tn I nun) 
e Ivwin I man j 



// Nog Oct is termmxJ output device 

// FUe. or file system sol device, as terminal output device 

'/ System axis strexra xs tcnnmxi output device 

// media Ctrl Object as cemunxJ output device 



// Disable VCO caJ! emuixoon mode 
// Enable VCO caii emuixoon mode 
11 Set remote host as a uscr-stxooo 
W Set remote host as an MCU 

// Emulau fxal VCO excepoon (recoverable in this exsc) 
// Emulate disc on line 1 
// Emulate disc on Ime 2 
// Emulate disc on Itne 1 at random t 
// Emulate disc on tine 2 at random c 
11 Emulate ringing on line 1 
// Emulate rtnfuif on tine 2 
II Emulate nngbacx on line I 
// Emulate rtngback on Itne 2 
II Emulate connect on line I 
// Emulate connect on tine 2 
// Emulate 1 line incoming, call 
II Emulate 2 line incoming call 
II Emulate 1 line outgoing call 
// Emulate 2 tine outgoing call 
II Emulate 1 tine outgoing call to bury remote 
11 FmuUu? 2 line outgoing call so busy remote 
// Emulate 1 line outgoing call that is rejected by remote 
' Emulate 2 line outgoing call that is rejected by remote 
Emulate 2 tine call » connect, the disc ro» by remote 
// Emulate | line audio-only call 
If Emulate I Itne audio-video call 
// Emulxte 2 line audio-video call 
II Emulate 2 line media col call 
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// MULTIPOINT CONTROL OPERATIONS ttTU-T H.231. ITU-T H.2«> 
typcdef cnum { 





SefiConfFocus. 


// Set conference focus to specified saaon 


3730 


QueryCon/Focus. 


// Determine iuuoo currently in conierence focus 




SctConfChair. 


// Set con/erence chairman 




QueryConiChair. 


// Dctermme current conierence chairmen 




AddSaooo. 


// Add staoon to conierence 




ReenoveScxoon. 


// Remove suoon from conierence 


3735 


BroadcastAudio. 


// Enable/ Disable broadcast of local audio to conferees 




BroadcauVideo. 


// Enable/Disable broadcast of local video to conferees 




BroadcastDao. 


// Enable/Disable broadcast of local dau to conferees 




GctNumScxocns . 


// Get number of conferees 




GctSaoonLui. 


// Get list of conferees 


3740 


GciSaooaCaps. 


// Get list of conferee capabuiaes 




GctSaaonAudio. 


// Get audio from parocular conferee 




GetStaaon Video. 


// Get video from particular conferee 




GeiSaconPaa. 


// Get data tram particular conferee 




Ge tStsoonidc noty . 


// Get numbers and f if possible) label for remote staoa 


3745 


MuloCailOpEnd 






) MULTICAIXOP; 





3750 



3755 



J760 



3765 



3770 



3775 



37TO 



3715 



3790 



// VCO UNrVEILSAL RESULT CODES 
( 



Redundant. 

RequctrOcrucd. 

H oclreptc meoced . 

NotS up poHCd. 

ProccxaTerrrunated. 

Capable, 

Incapable. 

MuatfieOpeoed. 

MuatBeClosed, 

Disabled. 

loUae. 

QucueEmpry. 
QueueFuil. 
Memory Alloc Error. 
ReacxuxcAlloc Error. 
tncernalError. 
TimerFamue. 



InvalidDataType. 

InvelidDevice Return. 

LrrvalidOperaooa, 

InvaJ idOperaoooNow . 

btvalidCapabtiify. 

InvaidModc. 

InvalidLine. 

lnvsaklNocfWr. 

loval aSObject. 

uTvaJaaScc&ng , 

InvaiidAHfim. 

CmdSynojLError, 

ArfSyntaxError. 

NotEnougufi and width. 

CallMustficConnccsed. 

NoCailForUneAdd. 

LtnclsOown. 

LineCortnectFtiied. 

LaneNocConnected . 

Linelxfiuiy. 

DttconncctRequesa. 



H Operaoon failed for some unspecified reason 
// Operaoon completed successfully 
// Operation is pending: standby for compteooo 
// Operaoon omed out 

// Operaoon sea mode or value that u already in force 

// Operaoon possible, but denied for some reason 

// Operaoon is not yet implemented, but is fonhcorairtg 

// Operaoon is not supported by dus tmptementaooo 

// Operaoon depends on process that has been terminated 

// System capable of r eques ted opera oon/cocftfuranon 

// System not capable of requested opcriaon/coa/iguraoon 

// Specified object must be opened prior to operaoon 

// Specified object must be closed poor to operaoon 

// Specified function disabled to prevent further system corruption 

// Specified object resource ts tn use by another process 

// Queue ts empty (no removable objects available) 

// Queue ts full (no more objects can be inserted) 

// Memory could not be allocated to support operaoon 

// Dependent resource could not be allocated due to error 

ft Some unexpected senous tncemal error was detected 

// Could not configure omer to modulate processing 

// Operaoon result indeterminate: don't know what happened 

// Specified taaon has invalid spec, or is for some reason unknown 

// Data specified for arg is of wrong type: such as a null per 

// Return code from device driver is unexpected or urucnown 

// Enumerated operaoon/ event is unknown 

// Enumerated ope ran on/ e rent is known, but unexpected at dus ome 

// Specified capability is unexpected or unknown 

// Specified mode ts unexpected or unknown 

// Specified line is unexpected or unknown 

// Specified no otter is unknown 

// Specified object is unknown 

// Specified seoang is unknown for this object 

// Specified parameter is unknown for mu sccong 

// Syntax error in 'command" poroon of message 

// Syntax error in "arg" poroon of message 

// Not enough bandwidth for requested operaoon 

// Operaoon only possible while connected to remote staoon 

// Attempt to add unknown conferee 

// Line has disconnected 

// Line connecoon fatted 

// Line has not yet fully connected 

// Line ts busy 

// Line disconnect is requested 
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3795 



3800 



3803 



3810 



3813 



3820 



3823 



3830 



3833 



3840 



3845 



// DISCONNECTION RESULT CODES 

DucSatus Undefined. 

DucSaoisNofnuJ. 

DtscSaatsPratDcolEnor. 

DiscSoau J)_Prc fixNotAJ lowed . 

DijcSaaisJ^PrcfzxNotAUowrd. 

DucSuou. I _ PrcfudRequircd . 

DiscSutxuinvalidNumdcr. 

DtscSuau InvalidAreaCode . 
DacSutusNumbetOuofcd. 
DiicSatuiRcmovBaiy. 
DUcSaau NoAatwer. 
DuxSaoisOIlRejecaed. 
DuxSatusJUnmceUnavailabte. 
DucSaoi&Nccwort£nor. 
DiseSatusCallPreeraptcd. 
DiscSaaaaOuta^uujBarred. 
Du^tttuxiocomuujBerred, 
DtscSoouQuaitcy UnavaiiaWe . 
DiicSaauComputtfRacUfttvadablg. 
DucSttauHWCoaftguriaon£m>r. 
DtscSatusCIUANocldic. 
DucSuuiaChanTypeNodinpiem. 
DtscSuauFicUicy NotSubscnbed I, 
Di ySf in iff icriiiyNodmoicm. 
DiscSanasNoRootToOest, 
DiicSaoulnvtJidNumberFonmt. 
DixcSauaNumberRequzred. 
ResultCodcEnd 
) RESULTCODE: 



FROM NETWORK 
ft Disc 
// Disc 
// Disc 
//Disc 
// Disc 
//Disc 
//Disc 
//Disc 
//Disc 
// Disc 
// Disc 
// Disc 
// Disc 
// Disc 
//Disc 
//Disc 
// Disc 
// Disc 
//Disc 
// Disc 
// Disc 
//Disc 
//Disc 
//Disc 
// Disc 
//Disc 
//Disc 



LAYER 
sacus indicates 
status indicates 
status indicates 
cams indicates 
taws indicates 
status indicates 
soajLs indicates 



undefined condition 



scams indicates 
status indicates 
nana indicates 
status indicates 
status indicates 



protocol eiroc 
tero prefix is not allowed 
one prcfia is not allowed 
one prefix is required 
invalid number 
mvaJid area code 
number has chanted 
remote tine a busy 



remote resected caU 
remote is unavailable 



status indicates 



status indicates 
status indicates 
satus indicates 
trams indicates 
wants indicates 
Mania indicates 
status indicates 
saats indicates 
status indicates 



call pre emp ted by other call 
outgoing calls are barred 
incoming calls are barred 
requested quality unavailable 
computer resource unavailable 
hardware configuration error 
channel not idle 
channel type not implemented 
facility not subsenbed 
facility not implemented 
no root to destMSaooo 
invalid number format 



ENUMERATED CALL CONTROL CONSTANTS 



tl tNDrVTDUAL LTNE STATES 
rypedef exsum { 

I iw- Disconnected, 

Line Dialed. 



Line Ring back. 
LtneConnected. 
UneSaaEnd 
) UNESTATE: 

// GENERAL CALL STATES 
rypedef enum ( 

CallDisconnBctcd. 

CailConneetutg. 

CaHConnecicd. 

CallSaaEnd 
) CALLSTATE; 



// Line is 
// Line ts dialed 
// Line a busy 

// Line a ringing at local station 
// Line is ringing at remote 
// Line is connected 



// Call is fully disconnected 



// Call is in t 
// Call is fully 



process of connecting 



3830 



3855 



// CALL DESTINATION 
rypedef enum { 

NoDe sanation. 

I nc al S etoon. 

RemoteSaoon. 

LocaiMCU. 

RemoaMCU. 
I CALLD5T: 



// No specific call destination determined 

// Cail to local stadon (incoming call) 

// Cail to remote somen (outgouig call) 

// Call to local mulopoiiu control una (incoming call) 

// Call to remote staoon (outgoing call) 
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// MULTIPOINT CALL STATE FLAGS 



3160 



3865 



3170 



3875 



3880 



3885 



3890 



3895 



3900 



IxMuldConaeccfid 


- 0*0001. 


// Locxi saoon « connected to mc 


ire than one remote tor MCtT) 


UConfFocus 


- Oiooca. 


II Local moon hxj conf erence foe 


an 


UCoafOuxr 


- 0x0004. 


// Local sttoon is conference chat 


man 


Is Rev mgConf Audio 


~ 0x0008. 


// Receiving conference audio 




liRcvuigCoa/Video 


=- 0x00 10. 


// Receiving conference video 




I j Rev tngC on/Data 


- 0<0020. 


// Receiving conference dau 




tiBrdcastmg Audio 


- 0x0040. 


// Broadcasung local audio 




UB idea song Video 


- 0x0080. 


// Broadcasting local video 




UBrdcasongDaa 


« 0x0100 


// Brotdcasong local dao 





) MULTICALLSTATE: 

// CONFERENCE CONNECTTVrTY PROFILE 
rvpedcf enum ( 

UscAudioOniy. 

UuVideoOniy. 

UseDaoOrUy. 

BeuDxoOnly. 

BcstAudioOnly. 

BeuVtdeoOoJy. 
) CONFTROFTLE; 

// DATA TRANSFER STATES 
typedef enum ( 

XferReady. 

XfcrrmiDia. 

XferRrtrytng. 

XferPeused. 

Xfcr Failure. 

xrerNocResponding . 

X f er Ina rnaiError . 
} XFERSTATE; 

// MEDIA DEVICE CONTROL STATES 
cypedef enum ( 

DeviceOpen. 

DcvieeQosed. 

DeviccFailed. 

Device Bury. 

DcvteeMClFailurc. 

Dc vice N out expending . 

DeviceinienuiError. 
) DEV1CEST ATE: 



// Audio sharing only 

// Video tax nag only 

// Dan snaring only 

// Priority to data inanng quality 

// Prionry to audio sharing quality 

// FTtonty ao video sharing duality 



// Ready to vansfcr (idle) 
// Transferring data 
// Trimfcr nrcrytng 
// Transfer paused 
// Transfer failed 

// Transfer process not responding 
// Transfer process internal error 



// Device u initialized and operaoonal 
// Device is not operaoonal 
// Device failed 

// Device is already in use and unavailable 

// Device driver fauure (Media Corurol Interface failure) 

// Device is not responding 

// Device internal error detected 
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3905 



3910 



3913 



3920 



3923 



3930 



3935 



3940 



3945 



3950 



3955 



" MEDIA CONTROL OBJECT TYPES 
rypedcf enum ( 
Audioln • 0. 
AudsoOui. 
AudsoSrc. 
AudioOst 
Videoln. 
VideoOut, 
VideoSrc. 
VkkoOu. 
Imagtlo. 
ImiftOui. 
ImageSrc. 
InugcOst. 
Detain. 
DataOut. 
DamSic. 
DaaDsc 
ObjTypeEnd 
J MCOjTrTE: 

// MEDIA CONTROL OBJECT SIGNAL TYPES 
rypedef enum { 

Sianalln m ObjTypeEnd. 

SifiMiOuc. 

StgnalSrc. 

SignalDsi 

SifnaJTypeEnd 
) MCO_SIGTYFE; 

it MEDIA CONTROL OBJECT COMPOSrTE TYPE 
Kief emim { ' ' 



'/ Audio signal from remote w** 
// Audio Signal to remote suoon 
// Audio Signal from tocai OeYce 
'/ Audio signal » local device 
// Motion-video from remote naoon 
" Motion-video to remote union 
" Mocton-vidco from local device 
" Moooo-vidco to local device 
" linage from remote saoon 
// Image to remote moon 
" Image from local device 
// Image to local device 
// Bit scream from remote tooon 
n B * «xeam to remote suoon 
H Bit stream from local device 
11 Bit stream to local device 



" wgnaJ from remote sooon 
U signal to remote staoon 
ti signal from local media 
// signal to local media control device 



SignalTypeEnd, 



Discreet 
Merged, 
Multiplexed. 
Demulaptcaed. 
Transformed. 
Composite TypeEnd 
} MCO^COMFTYPE; 

" DATA TRANSFER OBJECTS 
rypedef enum < 

X/erNoObfect - Composite Type End. 

XferCursorPos. 

XferSamg. 

XferTeaiFUe. 

XferfimFtle. 

XrerObjEnd 
) MCO XFEROBJ 



// Multiple inputs to same ouirapic oucputs 
*t Multiple mputt mixed into complex single 
" Multiple inputs encoded into single output 
" *«fle mput decoded into multiple oucpuo 
" «ngk mput subjected to specific trustor™ 



tt No specified data transfer object 

// Cursor Postoon 

// NullHernunaie ASC0 lest some 

" Teat file 

// Bmary file 



080021 SA1_l_j> 
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// MEDIA CONTROL OBJECT SETTINGS 



3960 



3970 



3973 



3980 



3983 



// BASE OBJECT SETTINGS 
NoSecang • XferObjEnd. 



Enable. 
Disable. 
On. 
Off. 

AoachTo. 

Detachfrom. 

AdoToCorapostte . 

Remove FrornComposite , 

SctCcmpotiteT ypc . 

GctSouus. 

GrtTipi, 

// MOTION-VIDEO SETTINGS 

SetCoicrkey. 

Aisi«n Window. 

Uroxngn Window. 

Resize Window, 

SctSmnehOn. 

SctSmctchOff. 

SeumageType, 

Freeze. 

Unfreeze. 

SeiProporocnaJCm. 

SctfYoporoonaiOrT. 

Set V ideo F nmeSize . 



il No specific semng 

// Open object nruiialue and render operaoenal) 
// CI ok object 

// Enable object (mike i variable for use) 

// Disable object (make unavailable for use* 

// Turn on object signal 

// Turn off object signal 

// Attach object signal to another object signal 

// Detach object signal from another object signal 

// Add object signal to composite signal 

// Remove object signal to composite signal 

II Set modal try of composite signal 

// Get staou of object signal 

// Get capabilities for object 



// Set mooon-video color-key vahic for display 

// Aiugn mooon-video display to specified window 

// Unaiaign mooon-video display from window 

// Resize (refresh and rtaiismjraooon-video window 

// Set mooon-video stretch mode on 

// Set mooon-video stretch mode off 

// Set mooon-video image type 

// Freeze mooon-video signal 

// Unfreeze motion- video signal 

// Set mooon-video proporoonaJ mode on 

// Set mooon-video proporoonaJ mode off 

// Set video frame sue 



// IMAGE SETTINGS 
3990 /■ Assign Window. 

Unaastgn Window . 

Resize Window. 

Sct ScretchOn. 

SetSoxtcbOfT. 
3995 SetlmageType. •/ 

SedmageMecnc. 

SctPixclWidth. 

SetPise Weight. 

SetPixelDepch. 
4000 SctftrysacaJWiddi. 

SctfbysicaiHerght. 

SctHorzPuelOrtgin. 

SesVenPuelOrigtn, 

SeoHorxPtry sicaiOrig uv 
4003 SetVenPtnrsicaiOngifi. 

SetHorzPixelDcnsuy. 

SetVcnPuetDcoirry. 

SetlmageCombtneType . 

4010 // AUDIO SETTINGS 

SetAudioQuaitty. 

LipSyncbOn. 

LipSyncbOff. 

EchoCancelOn. 
4015 EcboCancetOff. 

SetDTM FDurauon . 

LocaJDTMFPttlse. 

RemoceDTM FPulse . 



// Assign imaging display to window (already defined above) 
// Unaastgn imaging display from window (already defined above) 
// Resize (refresh/realign) imaging window (already defined above) 
// Set imaging stretch mode on (already defined above) 
// Set imaging stretch mode off (already defined above) 
// Set imaging image type (already defined above) 
// Set imaging image metric type 
// Set imaging image pixel width 
// Set imaging image pixel height 
// Set imaging image pixel depth 
// Set imaging image physical width 
// Set imaging image physical height 
// Set bonxonnu image pixel origin 
// Set verocai image pixel origin 
// Set bonzoaeal image physical origin 
// Set verocai image pixel origin 
// Set bonzonxai image pixel density 
// Set verocai image pixel density 
'// Set image c 



// Set audio signal quality 

// Turn on lip-rynchrontxaoon of audio signal to video signal 
// Turn off Irp-rynchjooxzaoon of audio signal to video signal 
// Turn echo canoe Uaboo on 
// Turn echo cancellation off 

// Set dial tone moduiaoon frequency pulse duraoon 
// Pulse DTMF at local staoon 
//Pulse DTMF at remote scaoon 



4020 



// DATA SETTINGS 

SetDsnJlste. 

SctSyncXferMode. 



// Set dao cranxfer rate 

// Set synchronous data transfer mode 
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SetAsyncXferMode. 
SctJUs<ncte4Mode. 
4025 SctUnrestnctedMode. 
McoSe tang End 
I MCOJCTTTNG: 

// 8 ASIC IMAGE TYPES 
4030 rypcdcf enum ( 

Notmage • McoSetongEnd. 
Colortottfc. 
Gray scale Image, 
Bimetal Image. 
4035 ImageTypeEnd 
) CMACETYPE: 



// Sec asynchronous aia en ruler mode 
// Set mine ted diu trxrurer mode 
// Set unrrsencted data transfer mode 



// No image tvnUble 
// Color image type 
11 GnyicAle image type 
type 



4040 



4045 



4050 



4055 



4060 



4065 



4070 



4075 



// IMAGE METRICS 
typedef enure ( 

InchMeaics - imafcTypcEnd. 

CendMcoacs. 

MiliiMetncs. 

MicroMecncs. 

lmagei*ecnc£nd 
} IMAGEMETTUC. 

// IMAGE -ON -{MAGE COMBINE TYPES 



( 

Overlay - ImageMemcEnd. 
Replace. 
Colorltey. 
OutLine, 
BitwtseOR. 
BtfwtseXOR. 
BtftrtscAND. 
ImageCombme Type End 
} IMAGECOMBTYPE: 

// MCmON-VIDEO FRAME SIZES (ITUT H.261) 
rypcdcf enum { 

NoVideo » IfnageCcmbineTypeEnd. 

QuancrCIF. 

FuUCIF. 

CIF240, 

4CIF. 

VideoSucEnd 
) YTDEOSIZE: 

// AUDIO SIGNAL QUALITY 
rypodef enum ( 

NoAudio — VideoSueEnd. 

VoiecLow. 

VotceHigo. 

Music. 

HigAFideliry. 

AudjoQuaJtryEnd 
) AUDIOQUALfTY; 



11 Set •inch' as primary measure 
H Set "centimeter* as primary measure 
// Set * millimeter- as primary measure 
// Set "micrometer* as primary measure 



// Overlay desonaoon widi source 
// Replace desonaoon wim source 

// Overlay desonaoon defined by colortey with i . _ 

// Overtay desonaoon wim temporary ouUine of source 
// Combine destination and source wnh bitwise OR 
// Combine desonaoon and source wife bitwise XOR 
// Combine desonaoon and source wub bitwise AND 



//No 

" Quarter-sue Common mtcrmeoaate Format video image 
// Full-size Common Intermediate Format video image 
// Common intermedia a: Format video image with 240 scanlmcs 
" Four-oroes Common Intermediate Format video image 



// No 

// Low quality voice signai (usually 4khx sample rate) 
// High quality voice signaj (usually 8-Uttu sample rate) 
// Music quality ngnai (usually 2 2 khz sample rate) 
// High fidelity quality signal (usually 44knz sample rate) 
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II DATA TRANSFER RATES 
typedef cnum ( 
4080 DitaJUteNone - AudioQualicyEnd. 

D»OLfUtc300. 

Da oJUtr 1 200 . 

DtcaJUte4*00. 

DataRate9600. 
4085 . DaoJUteMJCb. 

DataJRatcttKb. 

DscsJUtc64Kb. 

DtcUUtelUKb. 

DacaJUce 192Kb. 
4090 DtARate256Kb. 

OxttJtit«320Kb. 

DittJUtrJMKb. 

D*taRair5l2Kb. 

DataJUtell52Kb. 
4095 DaaJUte 1336Kb. 

DataJUteEnd 
) DATAJRATE. 



// No da a transfer 
// 300 baud transfer rate 
// 1200 baud transfer rate 
// 4800 baud truMfct rate 
// 9600 baud transfer rate 
// 14.4 kilobaud transfer race 
// 28.8 kilobaud transfer rate 
// 64 kilobaud transfer rate 
// 128 kilobaud transfer rate 
// 192 kilobaud transfer rate 
// 236 kilobaud transfer rate 
// 320 kilobaud transfer rate 
// 384 kilobaud transfer rate 
// 512 kilobaud transfer rate 
// 1 132 kilobaud transfer rate 
// 1536 kilobaud transfer rate 



// LAST VALID MCO TOKEN VALUE (USED FOR BOUNDS CHECKING OF ARGUMENTS) 
4100 cypedef enum { 

MedtaComroCToktoEnd ■» DataJUteEnd 

): 

m - -•-«---.-«----------------«---- — - — -- - — -- - — - 

4105 END CONTINUOUS LINEAR ENUMERATION OF MEDIA CONTROL OBJECT CONTROL TOKENS 



// STRUCTURE FOR VCO EVENT DESCRIPTOR 
struct tag EVENTREC { 
4110 DWORD Id: 

DWORD Panml: 
DWORD Ptram2; 
STATION* pStaoon: 
BOOL liFromDcvtce: 
4113 tagEVENTREC* pNeat: 

a g EVENTREC* pPrev: 
): 



II 32-bit VCO event identifier 
// 32-btt event parameter I 
// 32-btt event parameter 2 
// Ptr to source staooo 

// True if event generated by encapsulated device 

// Prr to neit event in queue or list 

// Ptr to previous event in queue or list 



4120 



4125 



4130 



typedef a g EVENTREC EVENTREC: 

// STRUCTURE FOR STATION DESCRIPTOR 
nrvfii tag STATION ( 
DWORD Id: 



BOOL 

tagSTATION- 
UgSTATION* 



pNumbcrUl; 

UVco; 

pNeac 



U 



rypedef ogSTATlON STATION: 



// System identifier/ index used co refer to this sooon 
/ Ptr to uaooa label 

II Amy of pen to numbers of remote i canon 

// True if remote taoon is determined to be a VCO 

// Ptr to neat i taoon ui last 

// Ptr to previous teaooo in list 



// DEFTNmON OF EVENT HANDLING MEMBER FUNCTION 

cypedef DWORD EVENTPROC( 

4135 EVENT Id. // 32-btt evew identifier 

DWORD 'Paraml. // 32 -bit event parameter 1 

DWORD ~ ParanU. // 32 -bit event parameter 2 

STATION* jxS cabon. // Prr to desenptor for taoon onginaang event 

HNOTIFIER* hNorifier // Handle to notification ooiect triggered by event 

4140 ): 
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4145 



4IS0 



4153 



4160 



4165 



4170 



4180 



4185 



'J,™™*? FOR VCO N OTIFIER OESCRJFTOR 
cypcdef struct { 

Triggers: 
pOe*ect: 
pMcnber: 
UEnabted: 
OniyOevtceEvcna. 
^Triggered: 
RexumDau: 



DWORD 
void* 

EVENTPROC 
BOOL 
BOOL 
long 

DWORD 

) NonnER; 

-mUCTVRE FOR RED-GREEN-BLUE COLOR SPECIFICATION 

BYTE o^. 

BYTE Green; " ^ color cornponent 

BYTE BhT^ " Green coior compooeni 

BYTE referred ,Ue CO,0f ^^Poriem 

) RCBVALUE: 

" STRUCTURE FOR DEVICE DESCRIPTOR 
rypedef struct ( 

DEV1CESTATE Stwe: 

ctMr * pUoel; 

ctur * pVentom 
(Objects; 



" Ptr to Noofier Receiver Obrect (NRO) 

J* 10 member of NRO 

" I" 1 * ^ noafief » c ^We4 to cnner 

// w ^ n ° nftCr ln « cr * °"*y fo' «eY«ce evenu 

/ D^^LlTt! 1 n ° Uf,Cr m " eral ^ reset 
" Data returned by naiificanon randier memoer of NRO 



HMCO 
} DEVICE: 



phMCO: 



" Sat * of physical device 
// Pw to label for physical device 
" Ptr to version stnnf for physical device 
£mber o, meda Ctrl ob^co associated with physical device 

tfTay of *r medu Ctrl ob,s associated w«Tae^ce 



4175 uu 



SSSf ^ MEOU COtmOL ° BJECT AUD «° "AAAMSTSRS 
AUDIOQUAUTY « MCO .u*. 

BOOL UE^CiLk*, ««»««'»'^lu TOB d,*.^ 

uu DTMRX^T Tom echo cncciUnoo u «i»btad 

» MCO.AUDIOPAJIAM: Di " Tone M «W»<>0" Frequency dunoan » msec 

F ° R MEDU COt ™ L "«r Mo-noN-v^o parameh*, 

tiAsiignedToWin; 
UWinUpdMcd: 
UFroxcn; 
IJProporooral; 
USseechcd: 
InufcType; 
VktooSue: 
pDtspUyWin; 



BOOL 
BOOL 
BOOL 
BOOL 
BOOL 

IMAGETYPE 
VtDEOSIZE 



I MCO VTDEOPAJIAM: 



11 Tw »* obj assigned w window 
// True if window .i.gned »«h source video urate 
" True rf mooon-video u frozen 
" True if mooon-rideo proportional mode cs on 
/'True if mooon-video stretch mode is on 
" Moaon-vidco image type 
'/ Moaon- video frame sue 
// Ptr to assigned display window 



wwv^wn <Mrtt»iiii i > 
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4190 



4195 



4200 



4205 



4210 



4215 



4230 



fi STRUCTURE FOR MEDIA CONTROL OBJECT IMAGING PARAMETERS 
lypedcf struct ( 



BOOL 


IsAsstg nedToWm: 


// 


BOOL 


liWmUpdated: 


// 


BOOL 


UFroxcm 


// 


BOOL 


IsPrepontonaJ: 


// 


BOOL 


IsSoxtcacd; 


// 


IMACETYPE 


BiacTjrpe: 


// 


1MAGECOMBTYPE 


CombTypc: 




(MAGEMETRIC 


tnut^Mcmc: 


// 


tnt 


PiidWidth: 


// 


UK 


PiiciHcifht: 


// 


tm 


PtxeiDepm: 


// 


tra 


H orzP ixc rOrigin: 


// 


tnt 


VenPuteJOrigin: 


// 


IW 


HoraPuclDcnsiry; 


// 


uu 


Ve nPueJ Density ; 


// 


uu 


Physical VYkim: 


// 


in 


PhyskalHetght: 


// 


us 


HortPhyftcaiOhffui: 


// 


tra 


VenPhyucal Origin: 


// 


Window 


pDupUyWm; 


// 



) MCO CMAGEPAJtAM; 

// STRUCTURE FOR MEDIA CONTROL OBJECT DATA PARAMETERS 
cypedcf struct { 

BOOL asynchronous: // True a* dam transfer u synchronous 

BOOL URestncted: It True if bandwidth is restricted 

BOOL ^Composite: // True if pan of < 

DATA-RATE TruuferRsxc: // Data ouuftf rate 

uu CompositcRatc: // Composite cramfer rate (if pan of composite) 

) M CO _ DAT AP ARAM ; 



4215 



4230 



4235 



4240 



// STRUCTURE FOR MEDIA CONTROL OBJECT 
cypedcf struct ngMCO ( 



MCO TYPE 

MCO SIGTYPE 

BOOL 

BOOL 

BOOL 

BOOL 

BOOL 

BOOL 

BOOL 

BOOL 

MCO AUDIOPARAM 
MCO_VIDEOPARAM 
MCOJMAGEPARAM 
MCO DATA? ARAM 
DEVICE* 
) M COP ARAM; 



OtojType: 
SigType: 
IsValid: 
UOpen; 



IsOr* 

IsAaached: 



IsBusy: 



Audio: 
Video: 
Image; 



pOcvicc: 



DESCRIPTOR 

// Ptr co Label for media col object 

// Media Ctrl object type 

// Media ctrt object signal type 

// True if media ctrt object is valid service or place holder 

// True if media ctrt object open 

// True if media ctrt object is enabled 

// True if media ctrt object is oo 

" True if media ctrt object is to another media coi object 

// True if media ctrt object is part of composite 

// True if media ctrt object is busy {unavailable) 

// True if signal is encode or compreased: false if not 

// Audio eeennsjs parameter Mock (if audio type) 

// Video parameter block (if video type) 

// Image parameter block (if image type) 

It Data parameter block (if data type) 

il Ptr to struct for device with which media ctrt object is associated 



" STRUCTURE FOR MEDIA CONTROL OBJECT BINDING RECORD 
struct ragMCOBlNDING ( 

4245 BOOL IsComp mit r: // True if binding is to produce composite signal 

tnt oSrc: // Number of source media Ctrl objects 

oDsr. // Number of desdnaoon media ctrt objects 

HMCO phMcoSrc: // Ptr to list of handles for source media ctrt objects 

HMCO phMcoDst: // Ptr to U« of handles for desonaoon media Ctrl object 

4250 QgMCO_ BINDING* pNeti: // Ptr to neat binding record 

tagMCO BINDING* pPrev: // Ptr to prev binding record 



rypedcf ogMCOBINDING MCO BINDING ; 
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4260 



4265 



4270 



4275 



4280 



4245 



4290 



4295 



4300 



4305 



4310 



4313 



4320 



F ° R MED1A C °™^ OBIECT COMMAND RECORD 
MCO_TYPE Type- 

MCO SETTING Seme* Tarf« media col object type 

DWORD Param " s * oaa « media Ctrl object 

J MCO CMD: " Ptrameter *nmi 

^^ABIUTY CROSS-REFERENCE RECORD (ITU-T H.22U 
DWORD vaiue- „ 

m ai^f,.' " ^ ode ° f c*p*bUUy value to be crou -referenced 

DEVICE DUTIES LISTING (ITU-T H.22I, 

BASCODE SS«Ca«.l- » . NUmbCr ° f H J21 "I**™ 

) OEVCAPS: ^ MUUpi,! " L^nf of H.22 1 device capabilities 

// STRUCTITRE FOR 
rypedcf nruct { 
OEVCAPS 
DEVCAPS 
DEVCAPS 



CAPABILITIES DATA (ITU-T H.22D 



Connect: 
nModes: 
nCaps; 

CapsfMaaCaptJ: 
Modc4(MaLRModes|: 



MEDIA CONTROL DEVICE PARAMETERS 



Deirices; 

DevfMaxDevicesI; 

Cap; 

rMco: 

AAudioObj; 

nVideoObj; 

nlmageObj: 

nDaaObj; 

pMcoUbelO: 

pMcoBurfim; 



hMco(Ma*McoTyp<|; 



XREF 
XREF 
I CAPS; 

// STRUCTURE FOR 
cypedef souct { 

coon tra 

conn DEVICE 

CAPS 

UK 

in 



conn char* 
MCO BINDING 
HMCO* 

HMCO 

} DEVI CEP ARAM; 



// STRUCTURE FOR CONFIGURATION AND 
•ypedef ttnici { 

UDynaPortable; 
BOOL UMulQCoonecable: 
BUOL UMuluinstanoable 
BOOL b Restricted 

BOOL 

STATION 
STATION 
cnar" 

in 
in 
in 
in 
in 
in 

ROB VALUE 
CONFPROFILE 
| CONFICPAJUM 



// LocaJ device capabilities listing 
" Remote devtec capabumcs usoxtg 
// Cortnecoviry (network interface) capabdmes tisane 
" Number cranes in -Modes to Caps* tref list 
// Number of entries m 'Caps to Modes' aref lit, 
// -Caps to Modes' iref list 
'/ 'Modes to Caps - xref list 



I ocaiSooon: 

RemoceSoooo; 

Te RnOuiputDe vice ; 

CoMeciTirneottt: 

Device Timeout: 

Dispatcher Rite: 

ScmccBand width: 

nLmeaA variable: 

fxLmesRequestcd: 

ColorKey: 

ConfProfUe; 



// "umber of encapsulated devices 
// Encapsulated device chain 
II H.221 capabilities for VCO devices 
" Number of media Ctrl objects currently available 

Umbgr o( * udAO objects currently available 
" Number of mooon-video objects 
H Number of image objects 
// Number of daa objects 
// Ptr to array of pas to media col object labels 
" Prr to linked list of current medu Ctrl object bindings 
' U '* lM o( to all avauabie media cut obiects 

" Default media cert ob*c, handles (reference w.m type 

SETUP PARAMETERS 

// True tf VCO is dynamically re-loadable at run-ome 
n x 1 , V ,2? SUpp0ra mulopotnt cootrol operaoons 
' " vco supports multiple concurrent instance* 
II True if service bandwidth is restricted 
// True if VCO tans up emulating devices 
'/ Label and numbers for local scaooa 
" Libel and numbers for default remote station 
II Default terminal output device or file name 
II Default connection timeout tn msec. 
// Default device timeout in msec. 
II Sarong dispatcher nie m msec. 
// Total service bandwidth available 
II Number of lines avauabie 
// Number of lines request for use by this VCO 
II colortey value for mooon-video 
// Conference profile 



OC©: <v¥O_0800213A1 JU* 
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" STRUCTURE FOR CALL CONTROL PARAMETERS FOR CURRENT CALL 
rypedef cruet ( 



4323 



4330 



433S 



CALL5TATE 


Sate; 


CONFPROFILE 


C en/Profile : 


CALLDST 


CaUDsc 


R£SULTCOOE 


DiscStanis: 


tin 

BOOL 


nLmes: 
IsRssstncted: 


BOOL 


IiCjJI Setup: 


BOOL 


isCaUmgVco: 


tra 


nGottfSeCOOOS: 


int 


Bandwidth: 


mi 




tm 


TimeSlots: 


LIN ESTATE 


UocSaic(3|: 


ini 


nS aaom: 


STATION 


pSaaocu: 



// Call stace for entire call 
// This conference profile 
II Dr to nation for call 

II Disconnect status (when in disconnected sate) 

// Tool number of lines to be used for this call 

// True if this call ts restricted 

// True if this call is seams; up 

" True if (his call desonaoon is another VCO 

'/ Number of current connections for this call 

II Total bandwidth used for dus call 

It OH connect omeout used for dus call 

// Timesiou used for dus call (if applicable) 

// Unestsce for each line tn call 

// Tool number of s noons involved in conference 

// Per » lisi of conference moons (first is local) 



4340 ■'/ MULTIPOINT CALL CONTROL PARAMETERS FOR CURJIENT CALL 



M ULTI C ALLSTATE 
BOOL 
BOOL 
BOOL 
4345 BOOL 
BOOL 
BOOL 
BOOL 
BOOL 

4350 } C ALU* ARAM; 



MulbCallStases: // Multipoint call status flag s 

IsConfFocus: // True if season has conference focus 

IsConfCbair; // True if season is conference chairman 

bRcviagConf Audio: // True if staoon is receiving conference audio 

bRcvitujConiVtdeo: ll True if season a receiving conference video 

URcvnujCon/Daa: // True tf staoon is receiving conference data 

LsBrdcastmgAudto: // True tf staoon is broadcasting audio 

IsBrdcasong Video: // True if season ts broadcasting video 

IsBrdcasangOan: // True if season is broadcasting data 



// STRUCTURE FOR CONNECTIVITY PROTOCOL PARAMETERS (ITU-T H.320. ITU-T H.221) 
r/pedef struct ( 



BOOL 

4355 BOOL 
BOOL 
BOOL 
BOOL 
BOOL 

4360 BASCODE 
BASCOOE 
BASCODE 
BASCODE 
BASCODE 

4365 BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 

4370 BASCODE 
BASCODE 



BASCODE 
4373 BASCODE 

) PROTOCOL* ARAM; 



UXsnnngAudio; // True if transmitting audio 

IsJCmhng Video: ' // True if transmitting video 

IsXmsingData: // True if cransmimng data 

IsRcvmgAudJO: // True if receiVtng audio 

URcvtngVideo: // True if receiving video 

LsRcvingData: // True if receiving data 

RcvDmtaJUte: // Current receive transfer raw 

RcvAudioMode: // Current receive audio mode 

RcvVadeoMode; // Current receive video mode 

RcvDataMode: // Current receive data mode 

XintDataJUte: // Current aim ma transfer rate 

XmsAudtoMode: // Current cransnui audio mode 

XmtVideoMode: // Current transmit video mode 

// Current transmn data mode 

// Pending transfer rate just set (pending XmtDataiUie) 
II Pending audio mode just set (pending XmtAudioMode) 
// Pending video mode just set ({sending Xmi Video Mode > 
// Pending da a mode just set (pending XmiDataMode) 
// Number of miscellaneous modes set by local staoon 
// Number of miscellaneous modes set by remote staoon 
MiscXtntModefMaxMiscMode): // List of miscellaneous mooes set by local staoon 
MtscRcvModcfMaaMiscMode): II Liu of miscellaneous mooes set by local staoon 



NewDaoJUte: 

NewAudioMode 

NewVsdeoMode: 

NcwDataMode: 

nMiscXmtMode: 

nMiscRcvMode: 



// STRUCTURE FOR REMOTE STATION CONTROL PARAMETERS 
rypedef struct { 

4380 BOOL IsAtBChed: // True if cmd and event stream aaactoed eo 

tsMaster: // True if controlling remote staoon (master) 

BOOL IsSlavc: // True if controlled by remote scaoon (slave) 

C0NTROLM0DE Modes: // Control mode setting flags 

CONTROLMODE Caps: // Control mode capa oil try /permission nags 

4383 | CONTROLPARAM: 



VCO 
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4J90 



4395 



4403 



4410 



^STRUCTURE FOR REMOTE STATION MONITORING PARAMETERS 



BOOL 
BOOL 
BOOL 
tnt 

STATION* 
MONTTORMODE 
MONtTORMODE 
) MONTTORPARAM: 



IsAaached: 



IsMonnored: 

cStMQcn: 

pSttOOiu; 

Modes: 

Caps; 



// True d event stream » cached to remote VCO 

// True rf monnonni at least one remote station 

" Tm * monitored by remote nanon 

// Number or staoons currendy monsaored 

" Ptr ao list or ttanons currently monitored 

// Monitor mode setnng flags 

" Monitor mooc capamlrry/pcrmusion fUfi 



—/SE^ VC ° SYSTEM INFORMATION fVCO PARAMETER BLOCK) 



char* 

VCOSTATE 
int 

BOOL 
BOOL 

DEVI CEP ARAM 
CON FIG P ARAM 
CALLPARAM 
PROTOCOLPARAM 
CONTROLPARAM 
MONITORPARAM 
) VCOPAJUM. 



pLafeet: 

p Version: 
Sous: 
RcfCount 
IsEmulaofuj: 
URcady; 
Device: 
Cocrfif: 
Call; 
Protocol; 
Control: 
Mo 



// Per to VCO label stntif 

" Ptr to VCO version sorutf 

It VCO global operanonai Mate 

// VCO reference count of users 

// True tf emulating devices 

// True tf ready to connect to remote station 

u VCO encapsulated device paramet er block 

// VCO configuration parameter block 

// VCO current call parameter block 

// VCO protocol parameter b lo ck 

// VCO conrrol contest parameter block 

" VCO monMonnf contest parameter block 
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CLASS VDI 

44 1 3 (Virtual Devtct Imerf act) 

Below n chc declaration for cite VCO Virtual Device Interface Class. An nuance of the VDI class muu contain, at a minimum, all 
of the (Miotic member functions use by VCO c Items to establish and control multimedia connectivity sessions with remote uaoons. 
This class muu also contain an instance of a VCO PA RAM data structure, and the pure virtual member declarations for the device 
4420 control member functions (hat provide device support to the puoitc member function inrnlmenaoons. The implementations for these 
pure virtual function* <de marked with the Dev < Label > symbolic naming convention i reside to the Pttriicai Debtee interface (class 
PDD. The constructor and destructor of this class, are protected members, and their public interface u via call from 
constructor/destructor m the more derived class VCO. 



class VDI: protected EVENT ( 



4425 



// MULTIMEDIA CONNECTION SYSTEM INFORMATION 
4430 VCOPARAM VcoParaen; 

// INTERNAL DEVICE INDEPENDENT MEMBERS GO HERE.. 



4435 

vtrtuaJ const char* GaiCtajsNamO ( return "VDI"; }; 

4440 NETWORK SESSION CONTROL 

--- — -- -- »- -- — -- -•--- — -- •-*/ 

VDI< char* _p(nfcFUe - 0 ); 
/• 

4445 USAGE: Construct the VirataJ Device interface for the VCO. 1/uaaJur VCO parameters and 

settings from die specified uuoalizaoon file. Setup devKe -independent data and code 
objects used by VCO. Create the default VCO device event noorter and ran the VCO 
er. 



4450 PARAM: j>uuiFde ...Filespec of file that contains VCO startup pa rams & settings. 

RETURN: none 

■/ 

44S5 virtual * VDIO; 

/• 

USAGE: Dcsouct the Virtual Device Interface. Save current scmngs to the tnraaJixaoon file. Close 
(he various media col objects, if open. Delete any nooftcrs and stop the VCO dispatcher. 
Free all resources allocated by VCO. 

4460 

PARAM: 



R£TURN: none 

•/ 

4465 public: 
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4470 



4475 



4435 



4490 



4495 



4500 



RESULTCOOE Open* BOOL _liBiockin f - | ); 

PA RAM: Ijfltockin* -r 

" no ^ c """' S b '« k "* * •* "« «»™ -no, congee, o, hi* a 

RETURN: Faiiun ""o-Olockin, * "~nu •mmduiely at -pewiw, • . 

Su cce ss 



Distbied 

Memory AJlocEmir 
R«*owceAiiocErTor 
ImenuJ Error 
TtmerfmihiK 

•/ 

RESULTCODE Clo*e< BOOL .IsB locsant - 1 ); 

USACE: ^^ £ rirr/, ~ r — - -~ - — 

^ ,yM€ms Frce rcjourcw i.tocaied for device control. 

PARAM: hBlockim t 

' noo^ock^ I* b,OCk,ng * WU1 °° l reW ™ Uftai or faUe rf 

n<m ^ >4ock,n « * return* immediately u pending-. 

RETURN: Failure 
Success 
Pendmt 
TunedOuc 
MuflfieOpeaod 
Dtssbted 

Memory AilocError 
Resource Alloc Error 
InsnaJEfTor 



J*- 



08OQ213M I > 



WO 98/09213 




PCT/US97/15018 



-177- 



4305 



4510 



4515 



4520 



4525 



4530 



RESULT CODE CaJM char- j>Numbcrl • 0. 

char* Number 2 • 0, 
BOOL _U Blocking - I ); 

/• 

USAGE: Eiobiuh initial call to remote moon, or MCU: create connecovtty session whose quality is 
determined by the highest common denominator of media cert connectivity services, 
as may be accommodated by bom local and remote staoons. A preference as to the quality of 
this interaction is expressed by each station: subsequently proceeds negotiation, between 
these stations, to establish the most appropriate media device interconnection modaXioes 
requisite to best fulfil inf die requests tor specific tat times con/1 icon* j conference profiles. 



PARAM: j)Numbert 

_p Number 2 

JsB locking 

RETURN: Faihire 
S ucces s 



TimedOut 
MustBcOpcned 
Disabled 
laUte 

Memory Alloc Error 

Resource Alloc Error 

InxcrnaiError 

TtmcrFauure 

InvalidDaraType 

NocEnoughfiandwidth 



...Ptr to string with number for line I. ouil calls default rctr 
...Ptr to stnng wnh number for line 2 (if used). 



...True if call is blocking & will not return unal comptete. or false if 
non-blocking 4. re rums immediately as 'pending'. 



4535 
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4540 



4545 



4550 



4553 



4560 



4565 



4570 



4575 



4500 



4585 



RESULTCODE MuiUCaU/ STATION- j>Sta<ioeu 
MULTICA1XOP Op 
DWORD P„«n . o 

bool ; UQttery . 0 

BOOt .bSJocklot - I ); 

USAGE. ^ * £ = n^upou. conrro* operaooo repeat to the 

ru«oon aiL, a^uX' » ptSSTl COOftCCtCd " ™ 'MCU1. This 

°irect tocaL/common mcdu cm to/from cotuerees. 



P ARAM: _Sca«Ki 
.Op 
_Parara 

tif>jery 
,UBtocking 



-Pit to .aeon descriptor specifying to which iauo« ope noon app4.es. 

Multipoint call control operation specifier 

Parameter for specified operation. 

.True if call is to query subsystem for operaooo capability. 

^Truc tf call u blockm, & will mm return until compete, or false if 
non-btockiruj A re rums immediately as -pending* 



MULTIPOINT CALL CONTROL OPERATION USAGE A PARAMETERS 
< -°* > < Par.ni > 



GcuNumScaooos 
GetStaoonJ nt 
GetSuooaCips 
GctSttoonJdcnmy 
...ail other ops 



Ptr to mt to receive count of moons tn con/ 
Per so buffer to hold linked list of STATION records 
Per to DEVCAPS record 

Ptr to STATION record to rev id of remote season 
Don't care 



RETURN: Failure 



Pendaruj 
TanedOut 



RequestDemed 
NotSupponed 
MuaxBeOpcned 
Disabled 



tnaernaiError 

InvmladSaoon 

InvaJidDaaType 

uivmlidOpermooA 

uwtJidOperaoonNow 

InvaiidPirmm 

CUIIMusaBeConnecied 

NoCsOIForLtneAdd 



«eo©2i3Ai_L> 
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RESULTCODE Haafupt ml aXJnt » 0 ); 
4590 /• 

USAGE: Han* -up enure catl to remote station, or MCU: tciecuveiy disconnect xpccifted line only. 

PARAM: aUnc ...Number of tinci to diiconncci: null hanfi up all lines. 

4595 RETURN: Failure 

Success 
TimedOut 
MunBcOpeued 
Disabled 

4600 IncenalError 

Invalid! mr 
CaOMustBcConncaed 
LmeJsOown 
LincNoiConnected 

4605 •/ 
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EVENT NOTIFICATION CONTROL 



4610 



4620 



4625 



4630 



4635 



4645 



4650 



4655 



RESULTCODE NrwN<*i/kr( HNOTlFTERA bNoUfltr 
EVEfOTOOC- IpMtnsber. 

4615 ,. DWORD SlSLk.O); 

PA RAM hNodiier p., 

* UCfTnce to fundJe «wi y created VCO noaftcaoon ob*ct. 

t>Meniber 

- Pit to ooufter receiver member oo process VCO events. 
" p0bKa -Pit id ooaficaaon receiver object. 

.Mtjit specifying events that will cngger noofier 

RETURN: Failure 
Success 
RequestDcrucd 
Disabled 
InvtlidDaaType 
InvahdParam 
Memory Alloc Error 
IntemaiError 



RESULTCODE DeteteNoUnerf HNOTIFCER bNoOAer ); 

USAGE: Delete VCO s.gna, a^ remove « from VCO linked | <tt . 
PAJUM. _hNoofie f .-Handle to signal to be deleted. 



RETURN: Failure 
Surrrti 
RcqucstDcnicd 
Disabled 
InvalidDataTypc 
Invalid* oafier 



RESULTCODE EnabieNoiim rt HNOTTFIER hNotilUr. 

BOOL ZUEanblcd - i ); 

USAGE: Enable or disable s.gnal from ^ on ,u speculed tnggenn, events. 

PARAM: hSignai w««hi. . 

... Handle to signal to be enabled or disabled. 

44560 .UEaabled ... Tnje mti cs signal mggenne; false disables tnggeru* 

RETURN: Failure 
Success 
Redundani 

4665 Outbid 

(nval id DataType 
InvaJidNoofier 
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RESULTCOOE SetNoliT»erTriu«"( HNOTTFTER hNotifler. 
4670 DWORD ~EveatMasJi - 0 ); 

/• 

USAGE: Set events that will cng|cr u*ml 

PARAM: hNoofter ...Handle to signal whose trigger cvems will be set. 

4475 

_EvereMask ...Mask specifying events mat will trigger signal. 

RETURN: Failure 
Success 

4680 Duabfed 

InvaJidDacaType 

IflVAlldNOOfKf 

•/ 

4685 RESULTCOOE T rigger No4ulen< EVENTREC* p£v«tuR*e. 

HNOTUTER 'hNotlAer - 0 ); 

/• 

USAGE: Triggers VCO notifters seruavc to the specified event, or aJtemaavely trigger » ipectfic stg ml 

4690 PARAM: j>Evcncft£C ...Prr to record conauung event parameters. 

hNoafter ...If specified, indicates specific signal » be triggered with event, or 

else all no a fieri sensmve to event are triggered. 

4695 RETURN: Failure 

Success 

Disabled 

InvalidDataType 

UivaiidNocirieff 
4700 InvaJidParam 
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47oj coNFiou^oN/seTuproro^oL" 

RESULTCODE Sc.Ccofl* CONFIGPARAM* jC^ , ; 

47,0 USACE; S " VCO «»<"*>™« d,„ ,o, n»„ cb.cc, ,* encp^ devlce , 

PA RAM _pConfif - 

• nr 60 rccord containing new conftguraoon 

RETURN: Failure 
Success 
RequcstDenied 
Disabled 

InvalidOataType 
InvrnJidFarmm 
Internal Error 
TtmerFauure 

•/ 

RESULTCODE StcreCooiigf CONFIGPARAM- j***, . 0 fc 
USAGE: Store VCO configuration to backing store. 
PA RAM: j>CaaTig 



4715 



4720 



4725 



4711) 

RETURN: Failure 



4735 



4740 



4745 



4750 



4755 



no^elT^? I 01 " 3 """ 1 "nfiguraaon to wnie to backing score If 
"one specified, tne current VCO cooiig is stored. 



RwyrrttfVmcd 
Disabled 
InvaJidDataType 
inraJidPmrara 
InaemaJError 
mf TimerFailure 

RESULTCODE RefresbCpoiu* COimCPAJUM- j>Coafi f - 0 >; 

USAGE: Refreshes current VCO configuring « r —r. 

0r "^^noon record from that saved in oacking store 

PARAM. _pConfig ^ 

Hwnea ' current VCO coring is refreshed. 

RETURN: Failure 
Success 
RecjucatDerued 



InvaitdDaoType 
tavrnJidPasani 
ImemaJ Error 
TimcrFauure 



<-v^r> ***r> oflno»i3Ai I > 
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4760 



RESULT/CODE Set upAudioD« vices* BOOL b Blocking « I ); 
/• 

USAGE: Invokes dulog box to enable interleave setup of audio devices. 

PARAM: JsBlockmg ...True if call is blocking St will not re rum una J complete: UUc tf 

non-blocking St returns immediately ms 'pending*. 



RETURN: Failure 
4763 Success 

Pending 
Redundant 
RequestDcnted 
NotSupporced 

4T70 Process Terminated 

MunBcOpened 
Disabled 
InUsc 

Memory AJloc Error 

4775 ResourccAllocError 

InwnuUErrof 

•/ 

RESULTCODE Setup Video Devices ( BOOL UB locking ■ I >; 
4780 /• 

USAGE: Invokes dialog bos to enable interactive setup of motion- video devices. 

PA RAM : _ Is Blocking ...True if call is blocking 6l will not return urmi complete: false if 

non- Woe king 6c rcmrro immediately as 'pending'. 

4783 

RETURN: Failure 
Success 
Pending 
Redundant 

4790 RequestDcmed 

NotSupporced 



MuatBeOpened 
Disabled 

4793 • InUsc 

Memory Alloc Error 
R e so ur c e AllocError 
Internal Error 

•/ 

4800 

RESULTCODE Set up Image Devices* BOOL Is Blocking - 1 ); 
/• 

USAGE: Invokes dialog boa to enable uueracovc setup of image devices. 

^ PARAM: Jifllocking ...True it call is blocking St wUI not return unoi complete: false if 

non-blocking St returns immediately as "pending* . 

RETURN: Faihire 
Success 

4810 Pending 



NocSupported 
ProccssTermtnaced 
**13 MustfieOpened 



InUae 

M emory Al loc Error 
Resource A Hoc Error 
4820 InaemaJ Error 
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RESULTCODE S*upDattl>«*cts< BOOL .IiBloctin, - | ,. 
4425 USAGE: Invoke* dialog bo, to e nitric iraeneavc -> ^ 

of «wo rt p^ „„,„„ ~LY|£ COnr,Iunnon °' "O pom. Soup 

PARAM: _U8 locking , ^ & ^ ^ ^ 

RETURN: F.Uun «o,n*K kul< 4 renjrm „ >allBf or *- " 

Success 

N ocSup po wm 
Pnxeu Terminated 
MtmBeOpmd 

lnU«e 

Memo ryAlloc Error 
RcwurceAlloc Error 
IiwenaiEnw 



4*45 



^■WMfV. -AA*r-\ aATMWCU-l I ^ 
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4450 



4833 



4860 



4865 



4870 



MEDIA CONTROL 

RESULTCODE McdinControll MCO TYFE .McoTvpe. 

MCO SETTING ~Scttenc* 

DWORD >amm - 0. 
BOOL IsQuery • 0. 

BOOL _UBloeking - I >; 



USAGE: Access service provided by encapsulated media control device by presenting media cert 
control setting to physical device control sub- system. 



PARAM: 



McoType 
^Setting 

_Pararn 

JsQuery 
IsBlockxng 



...Specific media Ctrl object rype for ope noon. 

...Audio-video-daia setnng constant specifying requested service 
desired from object. 

...If required, provides parameter necessary to fully speciry request to 
media Ctrl object. 

...True if call is to query sub-system for opcraoon capability 

...True if call is blocking Ac wilt not return oil complete, or false if 
non-blocking 4c returns immediately as 'pending*. 



MEDIA CONTROL OBJECT SETTIN GS A PARAMETERS 



4873 



< Pawn > 



BASE OBJECT SETTINGS: 



4883 



4890 



4893 



4900 



4903 



4910 



NoSccdng 

Open 

Close 

Enable 

Disable 

Oa 

Off 

AaachTo 

DcsachFrotn 
DectchAll 
AddToCamposue 
Remove FromComposite 
SetCompo site Type 



GctCaps 



...Don't care 
...Don't care 
...Don't care 
...Don't care 
...Don't care 
...Don't care 
...Don't care 

...MCO type to which lvalue MCO will be acocbed 
.- MCO type to which lvalue MCO will be anacbed 
...Don't care 

.Per to Ubel of MCO to add to lvalue MCO to create composite 
...Per to Ubel of MCO to remove from lvalue composite MCO 
...Value selected from one of < MCO COMPTYPE > 
...Adr of Ptr that will potm to parameter block appropriate 
for the lvalue MCO: that is. a will be ptr to one of : 

< MCO AUDIOPAJtAM > 

< MCO V [DEO P ARAM > 

< MCO LVtAGEPARAM > 

< MCO DAT AP ARAM > 

... < Piram > to whose capability ts directed such inquiry 



MEDIA CONTROL OBJECT SETTINGS A. PARAMETERS CONTINUED 
MOTION- VIDEO SETTINGS: 

SetColorkey ... < RGB VALUE > (cast to DWORD argument) 

Assign Window ...Ptr to unassigned window's data object 

UoassignWtndow ...Per to previously assigned wmdow's da a cbjeci 

Resize Window ...Per bo previously assigned window's data object 

SecStretcnOn ...Don't care 

SetStre echOff ...Don't care 

SetimageType ...Value selected from one of < IMAGETYPE > 

Freexe ...Don't care 

Unfreeze ...Don't care 

SetProporoonaiOn ...Don't care 

SctProporoonaiOfT ...Don't care 

SetVtdeoFrameSize ...Value selected from one of < VIDEOSIZE > 



WO 98/09213 

PCT/US97/15018 

186- 



4913 



4920 



4923 



4930 



4933 



4940 



4945 



4950 



4953 



4960 



4963 



4970 



4975 



IMAGING SETTINGS: 

AssignWtndow 

UiuuifnWtndow 

ReittcWirtow 

SetSnTtcnOn 

SeiSrochOff 

ScUmagcType 

SeUmifcMctnc 

SetPiaelWtftn 

SctftaclHetgb* 

S«PiaeU)epm 

SctPfaystcaiWidtfa 

SetPbyiicaJHetgitt 

SctHoreihxclOriftn 

SctVcnPixelOrigm 

SctHorxPhysiuiOrigifi 

SetVenPhysicaJOrtgin 

SciHorzPUclOensity 

SetV<npueIOensny 

SciinugcComtinetype 

AUDIO SETTINGS: 
SttAudioQuaJky 
SynchTo Video 
UnjyncWFrem Video 

EcboCancaJOfT 
SctDTMFDunooo 
tociiOTMFPulse 
<J RcmoceDTMFPuisc 

DATA SETTINGS: 

SetDataJUie 

SctSyncXfcrMode 

^tAjyncXferMode 

SetftcsoncsAdMode 

Setll nnstnciedMode 



• • Ptr to unassigned window « daa object 

previous assigned window » daa object 
-J* to previously .u.fncd window « daa object 

• Don't care "«p^ 

• Don't care 

Value selected from one of < IMAGETYTE > 

^^tt^T ooe * < [MACEMETWC > 

• Integer pixel count 
Inttfer pixel count 

•J«eter una according » current tnetnc 
• y «ceording to current mesne 
•j«e?er pud count (offset from left) 

• Integer ptxei count loffiet from op) 

I^H! ^ * CCORiin « 10 c*™* metnc (offset from left) 

• £**T ^ »cconlin« to unit, per current metrT 
-^ fer ** ci «"« icconittg to units per current m«nc 

Value selected from one of < 0^GECOMB£N^?^ > 

Value selected from one of < AUDIOQUALTTY > 

**eo obi Ubel from ^ ivaj V^unayec. 
-.Don't care 

-j^eier number of miUiacconos for duration 
-tager representing keypad button 
-loacger represcnang keypad I 



Value selected from 
..Don't care 

Don't care 
-Don't care 
-Don't care 



one of < DATAJUTE 



RETURN : Failure 
Success 



NotSupported 

Process Terminated 

Capable 

Incapable 

MufiBeOpened 

Disabled 



Memo ryAJIoc Error 
Resource AJlocError 
Internal Error 
Timer Fathtre 
UndefntedReault 
lovalalDeviceReoirn 
Invalid Ope raoon 
U^aJklOperaoonNow 
InvalidObject 
InvalidScmng 
InvalidParam 
NotEnoughfiandwidtb 



™*r> ©000213*1 j_> 
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RESULTCODE SetDefauUMe* MCO TVPE _ McoType. 

coon char* ~pMc*L»beJ >; 

/• 

4 **° USAGE: S« the VCO't default medu cal object for the specified abject type. 

PARAM: McoType Type of medu cal object to which default medu cal obfect wdJ be sex. 

jiMcoLabd Pa to label for medu cal obfect to set as default. 

RETURN: Failure 
Success 
Redundant 
NotSupponcd 
4990 MustBeOpeaed 

Disabled 
InUse 

IracmalEiTBr 
InvaJidDaaType 
4 W InvaJidOfaject 

UivalidSecanc 

•/ 

RESULTCODE SeiDefaultAfcof MCO TYPE McoType. 
5000 HMCO HMco >; 

/• 

USAGE: Set ttie VCO't default medu col object for the specified object type. 

PARAM: McoType -Type of media col object to which default medu col object wdl be set. 

5003 

hMco ...Handle of media cui object to set as default. 

RETURN: Failure 
Success 

5010 Redundant 

NotSupponcd 
MunficOpemd 
Disabled 
InUse 

3013 ImemaiEmr 

InvaJtdOaeitypc 

ImraiidObject 

InvalidSetnng 

•/ 

3020 
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5030 



5035 



5045 



5050 



5055 



5060 



5070 



PROTOCOL MANAGEMENT & CONTROL 
RESULTCODE SoCoolProHW COrtfFPROFILE PrortJ. >; 

acvice ""x^ 1 ippfopnaie to the specific cxii type. 



PARAM: profile - . , 

- 1 ype of coafcrence profile desired. 

RETURN: Future 
Success 
NotSupponed 
Disabled 



RESULTCODE SciMode* B AS CODE* jModeList. 
5040 ta .aMode* - | ) : 

USAGE: Attempt to sec H.221 dev.ee mode, for call m progress. 

Ptr to list limy, of H.221 mode combats u set. 
.nMode, Number of mode, m list. 

RETURN: Failure 
Success 
MustSeOpcaod 
Dtsabied 
litwnaiError 
ImftJidOaaType 
ImralidMode 
ImtiidPiram 
CsUMustBcConnectcd 



RESULTCODE ScadCsp«0; 

USACE 1™Z. ^ CiPlb '" U " 10 — — Mu„ 6c con_ or m ^ 0( Kami 
PARAM: none 



5065 RETURN: Ftiiurc 

Success 

MuatficOpeoed 
Disabled 
losensaiError 
LineUOown 
LoieNocConnected 
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RESULTC ODE Verify Band wvllb< BASCODE AucU©M»d«. 
3073 BASCODE DataMade ); 

/• 

USAGE: Determine if call has Rifficteni bandwidth to support the specified combination of audio and 



5095 



3100 



3080 PARAM. AudjoMode ...Requested H.221 audio mode. 

DaaModc ...Requested H.221 data mode. 

RETURN: Failure 
3085 Success 

NotSupp or ted 
MustBcOpetied 
Disabled 
InternalErroT 

5090 TimerFauure 

UndefinedJteaiiU 

[QvaiidMode 

CaJLMimBcCcnnccutd 



RESULTCODE SetDeviceTkneout< DWORD Msec); 
/• 

USAGE: Set default connecoon timeout value for encapsulated network interface in terms of how long 
a wtU watt for a response from die network. 

PAJLAM: _Msec ...Timeout value in milliseconds. 



RETURN: Failure 
Success 

3105 / MustBcOpened 

Disabled 
ImcrnaiError 
TunerFadure 
InvaJidPanm 

5110 •/ 

RESULTCODE SelCooxieci Timeout ( DWORD Msec ); 
/* 

USAGE: Set default connecoon timeout value for call controtler in terms of bow long it will wait for the 
5 1 13 entire call connecoon s equ en ce to complete. 

PARAM: _Msec ...Timeout value tn milliseconds. 

RETURN: Failure 
5120 Success 

MustBcOpened 

Disabled 

LnvalidParara 



5125 
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OATA EXCHANGE CO^oZ" 



5130 



5IJ5 



5140 



5M5 



5150 



5155 



5160 



5165 



TVansferBufTerf BYTE" 
lot 



USAGE: Traiufer buffer t 

PARAM: j>Buf 
_nfiyies 
J>McoLabel 
_U Query 
JsfiJocfctnt 



KCTURN: Failure 
Succsss 
Pending 
TunadOui 
RoquestDejued 
NotSwpported 
MustBcOpcned 
Disabled 
loUac 

Memory AllocError 
R«*>urccAJIocEmir 
Internal Error 
InvaJidOaeiType 
InvaJtfObjcct 

CAUMwcfleConnectcd 



-P«ttf, 

_aflrta « l. 
BOOL >Btoc*io f . | ) 



' ° f ^ rtmote depeiKJui, on *e : 



' rypc for the objcci. 

Ptr to (Ua buffer to transfer. 
Number of bytes to transfer. 

Ptr to label for medu cert data object, or null to oxlk.ee defadc 
True if call „ to query *ub-,y„em for operaoon capabU.ry 
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5170 



3175 



5180 



5185 



5190 



5195 



5200 



RESULTCODE TransfcrObjectC MCO XFEROBJ XferObj. 

XferOtjecf jXttrObl, 
coast char* _j>MCOLabel • 0. 

BOOL tsQocry « 0, 

BOOL UBtocking • 1 ): 

/• 

USAGE: Transfer dara object to or from remote saoon. depending on the signal rype for die object. 



PAJtAM: XfcfObj 

jjXferObject 
_pMcoLsbd 
UQuery 
^Blocking 



RETURN: Failure 
Success 



Pending 

TimedOut 

RequeuDemed 

NotimpteBittged 

HotSuppoffied 

MuttficOpcned 

Disabled 

InUsc 

Memory AJkjcEtror 

ResourceAlloc Error 

l/ucmal F.i tw 

lovalidDanType 

InvalidObject 

ImnJidParara 

CailMunBeConnected 



...Type of obfea to aamfcr. 

...Pit to tbe object's descriptor object containing specific informaooa. 

...Per to Ubcl for medu ciri data object, or null to iMjcate default. 

...True if call is to query sub-system for operaoon copabdiry. 

...True if cail is blocking St will not return until complete, or false tf 
non-Mocking 4c returns immediately as 'pending*. 
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5205 '•---«----......... 

TERMINAL SERVICE CONTROL 



5220 



5225 



5230 



5235 



5210 RESULTCODE To Terminal char" jFent, ...); 



USAGE: Wrwe data io the VCO terminal OUTPUT — 

number of irrumtnu. OUTPUT P °" 'ormat unr* and variable 



number of arguments 

PARAMr pFmt ^ , 

5215 - Ptr cd format imng. 



Variable number of 



text and data args. 



RETURN: Failure 
Success 
RequcstDcnied 
Disabled 
iaUsc 

InvalidOaaType 
InvalidPanm 



RESULTCODE rTaTenniaaif char* _pFtot, 



USAGE: Wmt data to the VCO irrmtrui ntrTDrrr ~_ 

to «r««,a. OirTPUT pon opocuMy uun» to™, «nn, i m „f p„ 



tOIDf. 



PARAM: j>Ftm .Ptr to format 

j>ArgLis< . (q |1M of p „ ^ jfg 

RETURN: Failure 



Success 
R-quesiDerued 
3 * 4U Disabled 

InUse 

liivalidDaaTypc 
tnvaiidParam 
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RESULTCODE FrotnTrrminaJI char* jiFmi, ...); 
/• 

USAGE: Write <Uo to the VCO tcrrmnai INPUT pon (VCO command imcrprrteri oooonaUy 
format wring snd list of ptrs to arguments. 

PARAM: j)Fmt ...Ptr to formal string. 

...Vsrabie mimfcer of test and data srgs. 

5255 RETURN: Failure 

Success 
RequejcOented 
Disabled 
InUtt 

5260 InvaJidDataType 

InvaJadParam 

♦/ 

RXSULTCODE » From Terminal char* jjFmi. 
5265 raid* _pArtUft ): 

/• 

USAGE: Write da a to the VCO terminal INPUT pon (VCO command interpreter) optionally using 
format suing and list of pus to arguments. 

5270 PARAM: jjFmt ...Ptr to format string. 

j>AfgLisc ... Ptr to list of ptrs co arg strings. 

RETURN: Failure 
5275 Success 

RequestDcnied 

Disabled 

InUae 

ImraiidDauType 
5280 InvalidParam 
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52J3 



5295 



5300 



3305 



5310 



5315 



5330 



5325 



RESULTCODE AtUchT.rmTaNoclfttrf HNOTTFIER _bH<xm*r U 

USAGE: ^ IT V VC ° IlT? *~ * » terrnxtu, OUTTXTT con .„ 
suram to the associated Nonfter Receiver Object (NRO). U,m *"* * u 

PAJUM: hNoofier Hmi , tn Mm , 

Mamie to signal to attach 

3290 RETURN: Failure 

Success 



Re qu est Dcmcd 

Disabled 

(nUsc 

InvaJtdNoufier 

•/ 



RESULTCODE AiuctaTermToFllef char- jFikspec. 

BOOL _UApptn4 - 0); 

USACE: " — » — — ou W per, _ 

PAJUM: .oFuespec .j* to fj e specificaoon of file co attach. 

- IlAPPCnd "** «» » * W"*d « current stream posioon; false if 

"ream pos. D on to be met at ame of itachemeni. 

RETURN: Failure 
Success 



RcqucatDefucd 

Disabled 

lftUse 

InvalidDaaType 



RESULTCODE AtUchTennToS4r«utD( rtrrsm ■ jvSaream, 

BOOL .UAppeod - 0 ); 

USACE ^~7s^ - ~ io o.rect ^ ou W 

PARAM: jvStream ...Ptr to stream to attach. 



JtAPPM Z*™ " "T "* * * »PP««W to current stream oosioon: false if 

«««« posmon co be reset at tune of araebmcm. 

5330 RETURN: Failure 



5335 



ReoucstDeiucd 

Disabled 

InvalidDaaType 
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RESULTCODE AtucfiTerrnToMeo* HMCO hMco. 

BOOL U Append m 0 \: 

5340 f 

USAGE: Attach media cui object as VCO terminal output device tn order to direct terminal output 
pon text stream to media cui object supporting data cransfcrs. 



5345 



5355 



5360 



5365 



5370 



PA RAM: hMco ...Handle to media czrt object to attach. 

Is Append ...True rf new text to be appended to current stream pox toon: false tf 

scream position to be reset at a me of machine at. 



RETURN: Failure 
5350 Success 



Redundant 
ReojuestDcrucd 
Disabled 
UwalidDataTypc 

•/ 

RESTJLTC ODE DctacfaTermf rom( TERMODEV OutpiuDev >; 

USAGE: Remove previously s cached signal. fUe. or data stream from the terminal output port. 
PARAM; OurputDev ..Terminal output device from which to detach terminal output. 

RETURN: Failure 



Disabled 
InUsc 

lrtvalidDaaType 
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3375 



3380 



3390 



5413 



5420 



SYSTEM INFORMATION CONTROL 

BOOL UReadyO; 
/• 

USAGE: Returns mic if VCO ts rudv tn m«b« • 

y W m,k£ mmaJ « u » remote suuon or mulopoim control unit. 

PARAM: none 



RETURN: True 
False 

3385 •/ 



BOOL IsCaUSetnpO; 

USAGE: Returns true while call u semng up. but i 
PARAM: none 



RETURN: True 
False 

5395 •/ 

BOOL IsCaiJO; 
/* 

5400 USACE: RcQJfTU oiie white «ll u fully connects to remote iaoon. 

PARAM: none 

RETURN: True 
False 

5405 ./ 

BOOL IsMulUCailO; 
/• 

3410 USAGE: Re0,TO ™ Wh " € «~« " — "™ one remote saoon or muiopo.m control urut. 

PARAM: none 



RETURN: True 
False 

•/ 

BOOL IsRemoteVcoO; 
/• 



USAGE: Returns one it remote saoon is • nmlopomi control , 
PARAM: none 



RETURN: True 
False 

5425 •/ 

BOOL URcmoceAOAcbedO ; 



. USAGE: Returns cue if remote saoon Vf O rn mn .,^ 

3430 »«aon vlu command am/or event soxam is accessible to local 

PARAM: none 
RETURN: True or False 



5435 
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BOOL LfMubUananuittdO: 

USAGE: Returns true %< this VCO is running wun more than one nuance. 
5440 PA RAM: none 

RETURN: True or False 

•/ 

5445 DEM CEP ARAM St GefDcvtctf aramO; 

/• 

USAGE: Returro reference to sodc buffer conrauung copy of VCO device parameter*. 



5450 



5475 



54*0 



PA RAM: none 

RETURN: Reference to copy of VCO device parameter block 



CONFIG P ARAM A GetCooitfParamO; 
5455 /• 

USAGE: Realms reference to race buffer containing copy of VCO coafig parameters. 
PA RAM: none 

5460 RETURN: Reference to copy of VCO configuraoon parameter block 

•/ 

CA1XPARAM& GetCaUPamO; 
5465 USAGE: Returns reference to staoc buffer containing copy of VCO call parameters. 

PARAM: none 

RETURN: Reference to copy of VCO call parameter block 

5470 •/ 

PROTOCOLPARAM& GetPnx ocoiParmasO : 

USAGE:- Returns reference to itaac buffer containing copy of VCO protocol parameters. 
PARAM: none 

RETURN: Reference to VCO protocol parameter block 

•/ 

CONTROLPARAM& GetCootrotParwO: 
/• 

USAGE: Returns reference to scaoc buffer containing copy of VCO control comes t parameters. 
54«5 PARAM: none 

RETURN: Reference to VCO control conceal parameter block 

•/ 

5490 MONTTORPARAM& GeiMon/iorPmraanO : 

/• 

USAGE: Returns reference to sane buffer containing copy of VCO monitor context parameters. 



5495 



PARAM: none 

RETURN: Reference to VCO monitor context parameter block 
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3500 



5505 



VCOPARAMA CetVcoPirvnO; 



5510 



5535 



5540 



5545 



USAGE: Return, reference to suae buffer containing copy of all VCO parameter,. 
PA RAM: none 



R€f€rence » VC <> .nfonranon parameter block 

MCOPAJtAM* GetMcoParam, MCO_TYPE _McoTyp« 

USAGE: Returns reference to suoc buffer conutnmg copy of media Ctrl parameter Woe. 
PARAM: McoType -Type of rnedu cul ob*ct 

5515 RcfCreftCe <° — oojec, parameter b.ock for specked media Ctrl object 

MCOPARAMA CelMcoParamt KM CO bMc© ): 

5520 USAGE; RetUnU " fc ™« - ~« cotuauur, copy of media cm parameter bloct 

PARAM: .HMco -.-Ha^ to rne^ co, ot^ 

KETVMi RC,CrenCe " mCdU COrt l»~r «ock for spectned media Ctrl ob^ 

5525 

VTDEOSIZE G«tV,de*Sxe< MCO^SICNALTYFE *gType - Sl^ >; 

USAGE: Return vdeo frame ,txe for default video object of speeded signal rype. 

3530 PARAM: SigType V u 

- 1 i7FB -Video ngraJ to examine for itxe 

RETURN: Emjmerated video frame sue value 



AUDIOQUAITTY G«iAudioQuality< MCO.SIGNAI.TYPE *,Type . Sta^lDat >; 
USAGE: Return qual.ty of default audio object of ipectrted signal rype. 

PARAM: SigType * ^ 

* Audio signal to examine for quality 

RETURN: Enumerated audio quality value 



GelimiModelUbeK BASCOOE Mode V 
char- G«Utt21C*pLebe!( BASCODE Cap/ 
^r* Gei^v>c«SU4ei-abd( DEYICESTaW DevaceSuie I- 
^G^ea^C^^abelfRESULTCODE S > 
cW Gei£rex»tLab«J( EVENT Eve* J. " 

5550 cooaa char* GetCailSUULebeJf C ALLSTATE " Ca^ 

ctwn char* G*ti*f>d^Ce/uyWTc4ietil^b*i< lot Mmjwn Vt"l 
const char- GetMcoLabe* HMC^wtto? -MediaC,rfTo4« >; 
cooaa char* GelMeoLehe* MCO TYPE McoType I- 
5555 C °°* ^ ^^"WC^OpLebei MULTICALLOP MulUCallO« i 

5555 CetSuUeaL-beU BOOL ^R^^^^ ' 

USAGE: Return per to tea, label specified wte or coruum item 
3360 PARAM: The specified state or com tar* 

RCTURN: w COIUam ™ng «' irgumcnx valid, else null 
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HMCO CclMcoKaodle< const char- j>McoL*b*l ); 
5563 /• 

USAGE: Reum handle to media Ctrl object specified by its label. 

PARAM j>Mco Label . Pu to label to media Ctrl object label. 

3570 RETURN: Handle to media col object specified by the label, else mail if no such media Ctrl object found. 

•/ 

HMCO CetMcoHandle{ MCO.TY7E .McoType ); 
/* 

5575 USAGE: Return handle to media ctrt object specified by its type. 

PA RAM: M co Type ...Media Ctrl object type. 

RETURN: Handle to media ctn object specified by the type, else mill if no such media Ctrl object found. 

3580 •/ 

RESULTCODE UstBewParminO: 

RESULTCODE UatCooXi«ParamO; 

RESULTCODE ListCaBParaunO; 
5535 RESULTCODE UstProtocolParmmO; 

RESULTCODE UstModeCapaXRctaO; 

RESULTCODE UstMCOBuwiieupO: 

RESULTCODE Ui*MCO*0: 

RESULTCODE UstNotuleraO: 
5590 RESULTCODE UrtCommindtQ; 

RESULTCODE l^TerainaJOutputaO: 

RESULTCODE LUtCots/erecsO; 

RESULTCODE LLstCocmecuooCapsO; 

RESULTCODE UxtMuWCailStatesO; 
5595 /• 

USAGE: Output formatted text luring for specified parameter groups 
PAJLAM: none 
5600 RETURN: Failure 



3610 



5625 



5630 



RESULTCODE UoMcoCapat MCO TYPE McoTyp*. 
5605 MCOSETTTNG .Settimj ); 

/• 

USAGE: Ouoput formaoed teat tisang of capabiltocs for specified default media ctrt object. 



PAJLAM: McoType ...Specific media crrl object to address 

Setcuruj ...Audto-vidco-daa setting corucant specifying requested service 

deai red from object. 



RETURN: Failure 
5615 Success 

Invalid Object 
LnvaJadSctong 

•/ 

5620 RESULTCODE ListStationCaps( STATION* _pSutioo - 0 ); 

/• 

USAGE. Output rormancd teat listing of H.221 capabilities for specified suoon. 



PARAM jxSaoon ...Pit to sooon desenptor (0 returns cips for local saoonj. 

RETURN: Failure 
Success 
InvalalScanon 



WO 98/09213 




PCTAJS97/15018 



-200- 



5435 



CONNECTION OBJECT C ONTO " 

RESULTCODE EnableVco* BOOL ^UEaabkd • 1 >; 

USAGE; Set VCO enable rta* «o true or fu tf ^ h 

* w true or false to chanye accessibility of VCO. 

PARAM tsEnabtcd T 
5640 ...True if VCO to be enabled: false to disable. 



5643 



5635 



3680 



3643 



RETURN: Failure 
Success 
Redundant 



RESULTCODE Set V^cepcMod. EXCEIHMODE Mode - 
USAGE: Set the current VCO ezcepuon handing tnodai^. 

3630 PARAM: Mode c 

— "«Poon handling mode denied . 

RETURN: Fadure 



Wrqueif Denied 
Nonsupported 



3660 MSULTCODE SetVcoTr»ceMode< TRACEMODE .Mod. - 0 ); 

USAGE: Set the current VCO trace output modality. 

PARAM: Mode T 

... Trace output mode de tired. 

5665 RETURN: FaUure 

Success 

Redundant 

RequestDemed 
3670 NotSupponcd 

RESULTCODE EnabieMulUCaJlOp* BOOL .UEaabled - I , ; 



PARAM: b Enabled 

• TfUe * f muJopomi control operacons to be enabled: false to disable 

RETURN: Failure 



Success 



**«**e*Deiued 

NotSupponed 

MustfieOpened 

Disabled 

IntemalError 
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RESULTCODE EnableDupatch<r< BOOL bEaabled - 1 ): 
5690 /• 

USAGE: Enable or disable the VCO dispatcher. 

PARAM: JiEnabied »Tiw tf VCO dispatcher operating; false rf not. 

5695 RETURN: Failure 

Success 
Redundant 
InUsc 

TunerFaiiuie 

5700 •/ 

RESULTCODE Queue£vem( EVENT 14. 

DWORD 'Pmal, 
WORD >.rmm2. 
3705 STATION • cvSuiioo - Q ); 

/* 

USAGE: Insca event into (he event queue. 

PARAM: Jd ...Ev«u identifier. 

5710 

Paraml ...First event parameter. 

Pa rami ...Second event parameter. 

5715 _pStmdoa ...p* id moon descriptor (null indicates local i canon). 

RETURN: Failure 



5725 



Queue Full 

*720 M emoryAlloc Error 

InvaliriSa o on 
Invalid DataTypc 
Invalid Ope rmoon 



RESULTCODE Set Dispatcher Rat e< tst Msec « DeraultDispateberRatc ); 



USAGE: Set the rate at which events are dispatched from the event queue 

5730 PARAM: _Msec ...Dispatch rate in milliseconds. 

RETURN: Failure 
Su 



5735 TtmcrFiUure 

InrvalidParam 
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5740 



5743 



5750 



5755 



5760 



5763 



5770 



5775 



5780 



57*5 



5790 



5795 



RESULTCODE UpdateCapsLmf BASCOOE Cap, 

char * .pCaplabel. 
BOOL .UNewC.p . l }; 

USAGE: Add or remove capability to/from local capabdity list. 



PARAM: _Cap 

_pCapLabel 
JsNewCaps 

RETURN; Failure 
Success 



-Capability < 
Pv to Ubcl for capabdity . 

-True if „ew cap, to add to list: false if cap co remove 



RequestDciued 
InvaJidDataType 
InvaiadCapabtltty 
IftvalidPinn 

•/ 

RESULTCODE UpdateModeCapsXReff XREF* ^XRef. 

/• BOOL .UNrwXRef « | 

USAGE: Add or remove mode^ap, crosi-refenmce to/from local list. 



PARAM: _pXRef 

IiNewXRef 

RETURN: Failure 
Success 



Ptr to modecaps cross -reference record. 
• True if new record co add: false if record to remove. 



RcqucstDented 

InvaiidOauType 

invaiidCapabuity 

RESULTCODE EmuCootrolf EMUCONTROLOP Op 
,. STATION* >StaU4oo - 0 > ; 

USAGE. Present emuiaoon control operation to a VCO. 

PARAM: Op c _ , 

- Y .fcmuiaoon corerol operaoon. 

" JXSeU> ° n .Ptrw> moon descriptor <nuil indicates local staoool. 

RETURN: Failure 
Suooeas 
Redundant 
RwyicstOemed 
NotSupported 
IntemalError 
Im-aiidOperaoon 
InrajidOpcraoonNow 
InvalidSaoon 
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REStTLTCODE AttacbToRecooteVco* BOOL IsMocutorOaly - 1. 

3800 BOOL 'LsBlocki&f - 1 ): 

/• 

USAGE: Cain access to the command and/or event stream of the remote moon. This action u only 
possible if the remote suuon is running a VCO for ru multimedia connection services. 

5805 PA RAM: IsMorutorOnJy True if requeu u only to monitor crte remote VCOs event stream. 

and not its command uream (for the purpose of mastering u). 

J sB locking ...True tf call u Mocking A. will not return una! complete, or false d 

non-Mocking A. returns immediately as * pending*. 

3810 RETURN: Failure 



58J5 



TtmcdOut 



5813 RemiestDenied 

NotSup ported 
Process Terminated 
MustBeOpened 



3125 



5S20 tflUsc 

InternaiExror 

UndcfmedResult 

CallMustBcConnecced 

•/ 

RESULTCODE D«LsenFroxnAcnso<eVco< BOOL U Bloc km r m | )• 

USAGE: Discard access gained to command and event stream of remote saoon. 

5830 PAJtAM: J sB locking ...True if call is blocking 6c will not return unoi complete, or false if 

non-Mocking Jt returns immediately as "pending*. 



RETURN: Failure 
Success 



3835 

Redundant 
RequcstDentcd 
NotSupponcd 
ProccssTc rrrunatcd 

3140 

In 

MustBeOpened 
laaefiulEiror 
Timer Failure 

5W5 UndcfmcdJUsuli 

CaXlMustBcConnected 



RESULTCODE Set VcoC on iroiMod* DWORD ModeFlap « Master I 
3830 /• 



USAGE: Set the mode of VCO control so that calls to member functions dnve the local or (he remote 
VCO. as configured. 

PAJLAM Mode Flags ...VCO control mode flags selected from < CONTROLMODE > 



RETURN: Failure 
Success 
Redundant 
RequcscDcnicd 
3860 Internal Error 

InvmlidOpcrmuon 

I nval idOpe ra ooruNo w 

CaJLMustBe Connected 

*/ 

3865 



ouennrwv jkur\ oano9iaA1 I > 
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MSULTCODE Se.VcoMc^orMod* DWORD ModeFlep - MooAlodeLocei > ; 

USAGE: Set the mode of VCO morutonna; wtfuime Bnm-WJ 

PARAM: _ModeFlagi Vrn _ 

- VCO monaor mode fl,« selected from < MOHTTORMODE > 

RETURN: Failure 
Success 
Redundant 
lUquestOcnted 
IraemaiError 
InnJidOpcrmooo 
InvtiidOperaocmNow 
CallMusu3eConnected 



3873 



5840 



R£SULTCODE SetSUiiool^beW eaar- JiLab€U 
3883 ***** _pN«ai; 

USAGE; Set label for the tocU station. 

PARAM: pLabeJ ~ 

~r -Pw to suaoa label. 

3890 . RETURN: Failure 

Success 

ImralidDaaType 
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5895 



~~ htEMBE ^ S BELOW ARE TO BE ACCESSED ONLY FOR THE IMPLEMENTATION 

OF THE ABOVE-DEFINED PUBLIC MEMBER FUNCTIONS THAT COMPRISE THE SOFTWARE CONTROI 
INTERFACE COMPONENT OF EACH VIRTUAL CONNECTION OBJECT 
THEY ARE NOT AVAILABLE TO CLIENT APPLICATIONS. 
5900 — 
prrrmcc: 

cypedef enum { 

€on< C"^ QXP * " inyokc OEM audio setup cornponcm 

5905 VrfcoSewp. „ Invoke OEM video scop component 

" lovok « OEM image setup component 

r!!?^ P * . " lr,voke OEM data setup component 

UpdateCapsUst. „ ^ or dev%ce „ pa0lllf y 

AoachToRemo<eVco. // Perform device operations to connect to remote VCO 

5910 Dcta^mn^emoteVco. // Perform device operations to deucb from remote VCO 

vendorSpeciftcOp. // Vendor-ipecific device control operaoons 

5915 lOComrolOpEnd 

I IOCONTROLOP: 



5920 



PURE VIRTUAL DEVICE CONTROL MEMBERS 
virtual RESULTCODE DevOpesi BOOL tiBlockiag • 1) 



USAGE: Open encapsulated doiccj. load and initialize OEM device coimol software and MCI device 
5TO drivers: prepare VCO to place outgo ins. or receive incoming call. 

PARAM: JsBtocking ...True if call is blocking & will not return unol complete, or false if 

non-Mocking 6c returns immediately as 'pending*. 

5930 RETURN: Failure 

Success 
Pending 
TimedOut 
Memory Alloc Error 
Resource Alloc Error 
Internal Error 
TimerFaUure 
InvaJidDevice Return 

•/ 



5940 



virtual RESULTCODE DevCtosef BOOL tsBlocking = I) • 0; 



USAGE: Close encapsulated devices, unload OEM dev,ce control loftw.re and drivers shutdown all 
systems related to establishing calls. 

5945 

PARAM: JsBtocking ...True if call is blocking & will not return una! compete, or false if 

non-blocking 4c returns immediately as 'pending*. 

RETURN: Failure 
5950 Success 

MuscBeOpcned 
MemoryAllocError 
Resource Alloc Error 
InatrnalError 

5955 •/ 



OMOOOCIO: <WO_ 930021 3A1JU> 
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5960 



5965 



5970 



5975 



5950 



5985 



5990 



5995 



6000 



6005 



6010 



6015 



6020 



nn«J RE5ULTCODE. D*rComiect< CALLPAJUMA CaUP«m. 

STATION* IpSimtton. 
/• BOOL .UWoclung - I ) . 0; 

USAGE; Connect to remote stanon or mulnpotm control unit. 



Reference 10 a VCO call parameter record. 

Ptr 10 rtmous 10000 descriptor to whet, connect u aestred. 

norI^ocl C « ^ blOCkin? * WU ' 001 fetUm Unul "■*«■. <>r false * 
non-olocking & returns immediately a* 'pending*. 



PA RAM CallParam 
_pS canon 
J*B locking 

RETURN: Failure 
Success 
Pending 
TimedOut 
MuxtBeOpencd 
InUse 

Memory Ailoc Error 
Reaource Alloc Error 
IruemaJ Error 
InvaJidScaoon 
InvaJadDataType 
LincConnectfaOed 
Line Is Busy 



nnual RESULTCODE D*rM«lliCoone«( MUI/HCAIXOP Op, 

CA1XPAHAM& 'CaflParmB. 
STATION* pSuttoa - 0 

BOOL w££-o 
/• BOOL liBiockmg « I ) • 0; 

USAGE, implement mulcipom. control operanon connect w ^ Qpomt coruro( uw , 



PA RAM: _Op 

.CallParam 
jxScaoon 
_UQuery 
JsBJocking 

RETURN: Failure 
Success 
Pending 
TtmadOut 

RcqueatDcnied 
NotSupponcd 
MuaeBcOpened 
InUtc 

M e mo ryAJloc Error 

Resource AllocError 

l/wernaJError 

InvalidSaaoo 

InvaJidDaaType 

InveiidOpcraaon 

InvaiidOperaoonNow 

CailMustBeConnected 

NoCaJIForLineAdd 



- Multipoint control operation. 
Reference to a VCO call parameter record 
• Ptr u> moon descriptor (or selected operation. 
•True if call is to query sub-syraem for ope noon cap.od.ry. 

oolZ'J^ 1 * WOCkjn « * WtU reuirn unol compute, or faJse «f 
nonlocking <Sc rerunu immedutely as 'pending-. 
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nrtuaJ RESULTCODE Dcv Disconnect! bit oliac • 0. 
6025 BOOl/UBlockmt - t ) - 0; 

/• 

USAGE: Disconnect one or more ttnes connected to remote tunon or multipoint control unit. 



6030 



PARAM nLmc ...Number of line to disconnect: null disconnects all lines 

_ Is Bloc king ...True rf call is blocking A will not return until complete, or false if 

non-Mocking 4c returns immediately as 'pending * 



RETURN: Failure 
6035 Success 

Pending 
TiraPdOut 



InUse 

6040 Memo ryAlloc Error 

ReaourceAlloc Error 
IncernalError 
InvaiidLine 
CallMustBeConnecxed 

6045 •/ 

virtual RESULTCODE DerAnjwer< CALX PA RAM A CaUPararn. 

tot nUne ) «= 0; 

/• 

6050 USAGE: Answer incoming call from remote station. 

PARAM: CallParam ...Reference to a VCO call parameter record. 

alone ...Number of line to disconnect: null disconnects all lines. 

RETURN: Fauure 

Su OOBtt 

MussflcOpened 



6055 



6060 Memory Alloc Error 

Resource AilocErro r 
LroemalError 
InvalidDuaTypc 
InvaiidLine 

6065 InvmlidOpertoonNow 

LincC o nnectFail ed 



nnual RESULTCODE DevAbortO - 0; 
6070 /• 



USAGE: Abort era re connection, or connecoon in progress, to remote moon or mulopotnt concroi unit. 
PARAM: 



6075 RETURN: Failure 

Success 
TunadOuf 
MttstfieOpened 
InUse 

6080 MemoryAtlocError 

ResourceAJIocError 
IncernalError 
CailMuscSeConnecied 

•/ 

6085 
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6095 



6100 



6105 



6120 



6125 



6130 



6135 



^ R£SULTCODE ^Caw., CALLPAJIAA14 CiUPmnm , 
USAGE: Get informs 
establishing 

PAKAM .CallParam 



USAGE: Get information for call or for 
^ esiablishine ,o mon^/caa p ^ ' eaU ' C " * — «"*coon 



-Reference to a VCO call parameter record. 
RETURN: Failure 
Success 
TimedOuc 
MustfieOpened 
MtutfieCloaed 
tnUae 

Memory AllocError 

ResourceAlJoc Error 

internal Error 

InvaJidOaaType 

UneNotConraected 

UneUButy 

OucortneciRequest 



R£SULTCODE D«„ M „l«C.„, aK MCO TYPE Mt . TtM 
6110 MCOJSETTTNC SrtUn/ ' 

DWORD >„^. 



BOOL .UO-^-o. 
/• BOOL _UB!ocfcinc - I ) - 0; 

usace: > y — - — «*-.» 



PARAM: (ume as MediaCortfrol) 
RETURN: Failure 



Pendant; 

TunedOut 

RequestDcnjcd 

MuacfieOpened 

InUse 

Memo ryAJ toe Error 

ReaourceAMoc Error 

ImemaiError 

TiraerFaihxrc 

Undefined Result 

InvaJidOaoType 

InvaiidOperaoon 

InvaiidOperauooNow 

Invalid Object 

UvalidSemnt; 

InvalidParam 
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TirtuaJ RESULTCODE DevEmuCooiraK EMUCONTROLOP Op > - 0; 
6140 /• 

USAGE: Implement cmuJauon control ope neon for this VCO. 
PAKAM: (umc as EmuConcroO 

6145 RETURN: Failure 

Success 

Redundant 

RcquestDemed 

MussBcOpeaed 
6150 Memory Alloc Error 

Resource Alloc Error 

IroemalError 

lavalidOpentna 

Invalid Ope raoonNow 

6155 •/ 
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6160 



6165 



6170 



6175 



6180 



6185 



6190 



6195 



6200 



6205 



6210 



6215 



6220 



WUaJ ^SULTCOOE D<rXmtD«M( BYTE* _p 8 uf. 

**** _oBn«* » i 

HMCO hMco • o 
BOOL >Qum « o, 
/• BOOL .bBlocfaaf « 1 > . 0: 

USAGE. T rlMm „ dlu „ nnmc m ^ t spec _ fK ^ 



PARAM: j)Bu/ 



JsBtockmg 

RETURN: Failure 
Success 
TunedOut 
NocSupponed 
MuKBeOpened 
InUte 

MerooryAIlocError 

Rooun*Alloc Error 

ImrrruiError 

InvtiKlDiaType 

l*v«iidOojeet 

InvAJidrHmn 

CiilMu5<fi«Connected 



-Ptr to buffer conuining <Ua. 
-Number of bytes to crarumrt. 

" Hma " a ob ' ecj - - <<» -» «™» fcr: nuJ1 Mtak 

W " UU) ^ ~««y~m for ope^oon c ipjWtty . 



"inual RESULTCODE DcvRcv DaLa< BYTE* 

lot 

HMCO 
BOOL 
BOOL 



_J»BuX. 
Clfljrtej m I 
bMco * 0, 
bQwry - 0. 
_Li Blocking « 1 ) - 0; 



USAGE: Po„ ^ „ ^ ^ fn)m _ _ for , ^ ^ 



PARAM: j> 8u f 
,nByecj 
_hMco 
.UQicry 
JiBlocking 

RETURN: Ftiiure 
Success 
TtmedOui 
NotSupported 
MustBeOpenod 
InUse 

Memory AJioc Error 

RciouaxAlloc Error 

ImenalErTor 

lAvaJidDiaType 

InvaJidObfccf 

InviiidPinm 

CaliMtutBeCorwected 



...Per to buffer containing daa. 
Number of bytei co transmit. 

H^die » d.« ob,cc. » u« for daa «™„ <CTT rjlll ^ 
•.T™. ,f ell „ «, query «!.,,«„, fot ope „ oon 
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6223 



6230 



6235 



6240 



6245 



virtual RESULTCODE DevSetModesf BASCODE* j>ModcUsi. 

i- I): 



USAGE: Attempt to set H. 22 1 device 
PA RAM: j>ModcUsc 

nModes 
RETURN: Failure 



for c&JI in progress. 
..Pu- id list (amy) of K.221 mode constants to set. 
..Number of modes in list. 



TtmedOut 

RequenDemcd 

MuscBcOpcned 

Memory AltocErro r 

Resource A I toe Error 

Lnienul Error 

InvaJidDaaType 

InvmlklModc 

IrtvsJidPafim 

CaJlMustfieConnccted 



6230 



6255 



6260 



6265 



virtual RESULTCODE DtvSendCapst BASCODE" _pCapUst. 

iot nCeps » I > • 0; 

/• 

USAGE: Transmit the specified capability set id the remote xzaoon. 

PARAM: (same as SendCaps) 

RETURN: Failure 
S ucces s 
TtmedOut 
RenuesiDerued 
MusiBcOpcned 
Memory Alloc Error 
ResourceAlloc Error 
UvemalError 
IrtvaiidDataType 
InvalidCapabattty 
tnvaiidParam 
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6275 



62S0 



6295 



6305 



6310 



6320 



6325 



6330 



6270 T°* COQSt ***** °«^«Wod^,b.M BASCODE .Mode 1 - 0; 

USAGE: Get text Ubcl for specified H.221 mode. 
PARAM: .Mode . HJ2 , mode conmw 

R£TURN: W co,uaw character «nn, if argument valid, else null 

jirtuai const char- OcvCetCaoUbeK BASCODE Cap > . 0; 
USAGE: Get text ubel for specified H.221 capability. 
PARAM: .Cap ...H.221 capability constant. 

62S5 R£TVRN: w COM * «™« * «gume« valid, else null 

virtual M CO PARAM A D«vG«iMeo< HMCO hMco ) - 0; 

6290 USACE: RCaini referenC€ W —* * ff « coruaxrunsj copy of medu Ctrl object parameter block 

PARAM: .hMco .Har^e to medu Ctrl c^ect. 

V RETTJRN: Refcrence » copy of media corl object parameter block for specified medu Ctrl ob,ec, 

virtual HMCO D«v<^tMcoH«ndie< coost char- _pMcoLabel > « 0; 
USAGE. Rearm handle to medu Ctrl object specified by it, ubel 
6300 PARAM: ^McoUbel ...Ptr * Ubel so medu Ctrl object Ubel. 

./ RSUm4 ' H ^ » medu ctrl object specified by the Ubel. else null if no such media Ctrl object found, 
virtual HMCO D~G*tMcoHandl<< MCO.TVFE _McoType ) « 0; 
USAGE: Reaim handle to medu cert object specified by ,u type. 
PARAM: .McoType ... Medi , ea| ^ ^ 

•/ R£TURN:Hli,dlC * Cff1 IV *e type, else null if no such medu Ctrl object four*. 

m 5 ™ual RESUl/TCODE DevSetOefauiiMc* MCO.TYPE .McoType. 

«i*r* jjMcolJibel ) - 0; 
USAGE: Set me VCO's default medu col object for mc specified object type. 
PARAM. .McoType .Type ot medu ccri object to which the default wui be set. 



_pMcoLabe! ...Ptr to Ubel for media Ctrl object to set as default. 

RETURN: Failure 
Success 
Redundant 
NotSupponed 
MustBeOpened 
Disabled 
IaUsc 

InternaiError 
InvalidOaaType 
InvtJidObfcci 
InvaiidSeairuj 
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6340 



nntal RESULTCODE DevSetDefauKMco< MCO TYPE McoTypt. 

HMCO "hMco ) - 0; 

/• 

USAGE: Set the VCO'i default medu Ctrl object for the specified object type. 

PARAM: _McoType -Type of medu col object to wtuch default medu carl object wtll be set. 

hMco ...Handle of medu Ctrl object to set as default. 



6345 RETURN: Failure 

Success 



NocSupporicd 
M dStfi eOpc ncd 
6350 Disabled 

InUse 

Internal Error 

IrtvaJidDataType 

InvalidObject 

6355 InvaltdSeaxnt 



virtual RESULTCODE DetSeiTtmeouK DWORD NU« » - 0; 

6360 USAGE: Set connect timeout for network iroenxce unit. 

PARAM: Msec ...Timeout value in mUliseconas. 

RETURN: Failure 
6363 Success 

TimedOuf 



Memory Alloc Error 
6370 ReaourceAJloc Error 

IruemaiError 
Timerfariurc 
Invalid Da taType 
unvaltdPiram 

6375 •/ 

virtual RESULTCODE De*VertfyBaodwidfb( BA5CODE AudioMode, 

BASCODE "DauModt I » 0: 

/• 

6380 USAGE: Verify thai connecoon das sufficient bandwidth for specified audio-data mode comoinaooo. 

with respect to the current video mode (if applicable). 

PARAM: _ AudioMode ...H.221 audio mode. 

6385 DanMode ...H.221 daa mode. 

RETURN: TimedOuf 



6390 MttstfieOpcned 



Memory Alloc Error 
Resource Alloc Error 
Internal Error 

6395 InvalidMode 

CallMustBcConnecced 
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6400 



6405 



6410 



6415 



6420 



6425 



6430 



irtuai R£5ULTCOD£ DeWOComrolf lOCOTOOLOP Op 

DWORD Pat^sl . 0. 

DWORD 'Pmau . 

BOOL UQutry - 4. 

/• BO °L _bBlockin< - | > 



USAGE: 



6435 



6440 



ooiptoner.. TTm member ft^TL """^ mtmo « 

cudy-iocumcmra ejitnnoMB^ Provided u « meciunura to twdd ttmemred. 

input/ourpui device control operation requested. 
If required, prov.des parameter necessary to fully specify request, 
if required. provides parameter necessary to fully ipcc.fy rrqueu 
True rf call is to query subsystem for opera oon capabti.ry. 

r^L^'i 1 blOCkin * * WU * ^ " m ™« com *<*. or false if 
non-Woe lung & re turns immediately as * pending- 



PARAM: Op 

_Paraml 
_ Parana 
UQuery 
JsBlocaung 

RETURN : Failure 
Success 



P endin g 

TunedOut 

RequeasDeued 

MustfleOpened 

InU*e 

MatnoryAllocErTor 
ReaourceAJlocError 
Lrxerrui£rror 
TimerFaihire 
UndefinedAcsult 
lnvaiidDaaType 
tnvaladOpcraooo 
InvmlidOperaoonNow 
InvalidParam 
-Others according to implemcmaoon requiremems 
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B IT-RATE ALLOCATION SIGNAL HEADER FILE 



6443 



6450 



645S 



6460 



SAMPLE HEADER FILE 
for 

HJ221 BIT-RATE ALLOCATION SIGNALS 
used to indicate 
DEVICE MODES AND CAPABILITIES 

ABSTRACT 

This source module conouu header in/orrnauoo that will provide a device -independent core seraataon of bti-raie silocaoon signal 

C OtHfl U mdl (B AS COdC SI tl~\ irv4u»ar* ti^vtrm mm4m «fu4 « rs« K*J .n^»« •i-rnM4rM M rfia U lift f _ i . . 



coimunu idao coqcsi used to indicate device modes and capaodiaes according to the H.320 (specifically H 22 D 
Recommeodaoon. These lists are intended for Ulustaave purposes, and are incomplete. An impl e m e ntation of a VMCS would need 
co define a complete list, and then preserve the exact numerical identity of these constants for all imptctnenaoons intended for 
interoperability within the same operating environment. vinuaJizaoon routines in (he VL (of VCO implementations i must translate 
these dence -independent versions of H.221 modes and capabdioes into the actual BAS codes formats specified by the 
reconunendaoon for line transmission. 

(SOURCE FILE. BASCODESH) 



6463 



PROGRAMMING NOTES 
This module contain* only C+ •+ source code and structured commenu using the " // 4 
the standard C comment notation using •/••/"). 



i to denote comments (in addioon to 



BIT. RATE ALLOCATION SIGNALS TO INDICATE DEVICE 
6470 CAPABILITIES (DEVICE MODE CAPABILITIES* 



// TRANSFER RATE CAPABILITIES 
BASCODE CapTnosferlUt«64 

6473 BASCODE CapTnnsferR*te2a*4 
BASCODE CapTrmnsferRaicJs64 
BASCODE CapTnnsferRa4*4e*4 
BASCODE CapTrans/erRat*3x64 
BASCODE CapTnnsfcrRa4c*a*4 

6480 BASCODE CapTnasferRato3S4 

BASCODE CepTrmnsferRatelaJW 
BASCODE CapTransYerlUteJx384 
BASCODE CapTraxisferRAte4s384 
BASCODE CapTr*nsferRate5xJ&4 

6455 BASCODE CapTransferR*uL536 
BASCODE CepTraxufcxRaleinO 
BASCODE CapTr*mferRaul28 
BASCODE CapTrtnsf ex Rate IP2 
BASCODE CapTraxasferRata254 

6490 BASCODE C*p Transfer RaieSU 
BASCODE CapTransferRaU76J 
BASCODE CapTrsusxferR*t«llS2 
BASCODE C*pTrmrtsferRatei472 
BASCODE CapRestfict 

6493 BASCODE < 



- 0x80000001 
• 0**0000002 



- 0x80000003 
™ 0x80000004: 

- 0x80000005 



• 0x80000006: 



* 0x80000007; 
» 0x80000008 
' 0x80000009; 

* OxSOOOOC 

* 0x8000000b 

* 0x8000000c 

* OxSOOOOOOd; 
■ OxSOOOOOOe 



■ OxSOOOOOOf: 

• 0x80000010; 

• 0a8 00 00030' 
1 0x80000030; 
» 0x80000040 

• O: 
- 0; 

• 0x80000 0 70; 



//AUDIO CAPABILITIES 
BASCODE CapAudioALa w 
BASCODE CapAodloULaw 
6500 BASCODE GapAodioGTB 64 
BASCODE CapAodioGTO 48 
BASCODE C jpAueUoGTa ~ 
BASCODE CapAudlotSO 



1 0x80000080 



» 0 x 80000090: 
• O aJ OOOOC 
- OxSOOOOOfcO; 



- Ox800000cO; 



- 0x80000040: 



6303 //VIDEO CAPABILmES 

BASCODE CapVideoQCtTl 
BASCODE CxpVldtoQClF2 



- OxfiOOOOOeO: 
™ 0x800000(0; 



WO 98/09213 




PCT/US97/150I8 



-216- 



6510 



6515 



6520 



6523 



6530 



6535 



6540 



6545 



6550 



6555 



6560 



6565 



6570 



BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 



CapVideoQCin 
CapVld«oQCtF4 
CapVidcoCIFl 

c. P vid«ocm 

CapVirfcoCTO 
CapVld«oClT4 
CapVldco Lmprvvtd 
CapVidaalSO 
CapVid«oCompa«at« 



- 0x80000100: 

- 0x80000200; 



• 0x80000300 

- 0x80000400; 

- 0x80000500: 

- 0x80000600; 

- 0x80000700: 

- 0x80000800; 

- 0x80000900: 



//IMAGE CAPABILITIES 
BASCODE CapSuatilPteturtLowSp««dD«u 
BASCODE CapSuntOPlcxunUJ«hSp««d£>ata 
BASCODE CapStmiilPicturcSpaUaiModc 
BASCODE CapSiiMilPictitrcPrvcrasmModc 
BASCODE CapSuatiIPlctortAnihm«UcM«d« 
BASCODE CapSttatiiPlctitr»il241 
BASCODE CapGroupJFu 
BASCODE CapCroup4Fax 

//LOW SPEED DATA CAPABILITIES 
BASCODE CapL«wSpe«dDaUVarfabl« 
BASCODE CapLawSpcadDataMO 
BASCODE Capj awSp— dDaUUOO 
BASCODE CapLe«SpccdI>at«4M0 
BASCODE CapLowSptdDala4 400 
BASCODE CapLawSpecdDataMOO 
BASCODE Cap! awSp— dOfJiOO 
BASCODE CapL M S pM dDa4ai4400 
BASCOOE CaplawSp— dDtaldX 
BASCODE CapLowSp««dDmta24K 
BASCODE CapLowSpeadDatattlC 
BASCODE Cap! awSp— dPatadOK 
BASCODE CapL*wSpc«dDaia4*K 
BASCODE CapLawSpccdDataSOC 
BASCODE CapLowSpc«dDala43K 
BASCODE Cap! — SpaadData4>4K 

// HIGH SPEED DATA CAPABILITIES 
BASCODE CapHicfaSpc«dDa<aMK 
BASCODE CapHi«>Spc«dD«Ul2SK 
BASCODE CapHifhSpwdDatalttK 
BASCODE CapHiajaS pcadD aUlSiK 
BASCODE CapHl8hSp»adDmtoI20K 
BASCODE CapHjghSpc«dD«ta3a4K 
BASCODE CapHlgfaSpacdDataSUK 
BASCODE CapHithSpwiDrtaTaK 
BASCODE CapajfbSp*cdD«Ull52K 
BASCODE CapHifhSpt<dDautS341C 
BASCODE CapHif*iSpe«tfU)*u 

//APPLICATION CAPABILITIES 
BASCODE CapEacrypUao 
BASCODE CapGcapbkaCunar 
BASCODE CapVUOLavSpecdDau 
BASCODE CapVUOHlthSpccdDau 

//MULTIPOINT CONTROL CAPABILITIES (VCO 

BASCODE CapSctCoa/Focu* 

BASCODE CapQuerrCoufFaoif 

BASCODE CapSci CoofCfcair 

BASCODE CapQutrrCoolClialr 

BASCODE CapAddSuUoa 

BASCODE CapRamercSutioa 

BASCODE CapfiraadcaaxAudto 

BASCODE CapBroaakaat Video 

BASCODE CapflrotdcanData 



- 0x80000b00: 

- 0x80000c00: 

- 0*80000rf00: 

- 0x80000e00; 

- Ox8O000*»; 

- 0x80001000: 

- 0x80002000: 



- 0x80003000; 
• 0x80004000: 

- 0x80005000; 

- 0x80006000; 



• 0x80007000 



' 0x80008000; 



- OxSOOOKXXh 

- OxBOOOaOOQ; 



- OxIOOObOOO: 
• OxSOOOcOOO: 

- OxBOOOdOOO: 



' 0x8O00c000; 
' OxBOOOfDOO: 
' 0x80010000: 
' 0x80020000: 
' 0x80030000: 



- 0x80040000: 
-0x80050000: 
-0x80060000; 

- 0x80070000: 

- 0x80080000; 



• 0x80090000; 
' 0x800x0000; 

• OxSOObOOOO 
' OxSOOcOOOO; 
1 Ox800d0000: 



- OxSOOcOOOO: 



• 0x80010000; 

0x80100000 
1 0x80200000; 



-0x80300000; 

PROPRIETARY) 

- 0x80400000; 

- 0x80400001 

- 0x80400002 
-0x80400003 
-0x80400004 

- 0x80400005 

- 0x80400006; 

- 0x80400007 

- 0x80400008 
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6575 



6580 



BASCODE 
BASCODE 
B AS CODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 



CapC«tNamSi*tioQ» 

CapGclSUtioaUsS 

CUpOrtStxliooCxp* 

CUpGctStttioaAudio 

C»pOtSi40ooV*d*« 

C*pG«tSutioaDsu 

CapGttSutiooJdestiir 



- 0x80*00009: 

° 0x804000031 
« 0x8O40000b 

• 0x«O4O0C 

• 0x8O4O000d 

• 0x6040000e 

• 0x8O4O00Of: 



6585 



BIT-RATE ALLOCATION SIGNALS TO SET DEVICE MODES 
(DEVICE MODE COMMANDS! 



// TRANSFER RATE MODES 
BASCODE ModeTnarfcrRjtc** 

6590 BASCODE ModcTransferR*ie2s£4 
BASCODE Mod«TraasftrRateJx64 
BASCODE ModcTro*/«rRai«4*64 
BASCODE M«4tTransferRAUSs64 
BASCODE Mod*Tnn»fcrR*i«*«*4 

6595 BASCODE MtfdeTnasf«rRfttc3S4 
BASCODE Mod«TnmlcrRat«2m3S4 
BASCODE ModcTnnff«rR*le3m3S4 
BASCODE ModeTruBf«rRjt*4x3S 
BASCODE M«d*Tnmi'trR*xtSJLU4 

66O0 BASCODE ModcTrmnsicrRMci536 
BASCODE ModtTrmmferRjrteira 
BASCODE M«deTrmosferR*UUS 
BASCODE ModtTrmmfcrRalclTZ 
BASCODE Mod«TnnxfcrRj*t256 

6605 BASCODE ModtTrmnxierftitcSU 
BASCODE M<MkTmwlcrRxl«768 
BASCODE Mod«Traas<«rR*ull52 
BASCODE ModaTrmnxlcrRxcUTZ 



• Oil oooooo t 

> 0k 10000002 

> 0*10000003 

• 0x10000004 

• 0x10000005 

> 0x10000006; 

• 0x10000007: 
» 0x10000008 

■ 0x10000009: 

• Ox 1 0 00000a; 

• Ox 1000000b 

• Ox 1000000c; 

■ OxlOOOOOOd; 
» OxlOOOOOOe 

• OxIOOOOOOf; 

■ 0x10000010: 

■ 0x10000020; 

■ 0x10000030; 

• ^ 1 00000 40 

■ 0x10000050; 



6610 



6615 



6620 



6625 



6630 



6635 



// AUDIO MODES 
BASCODE MocUAudioOfT I 
BASCODE Mod*AudJoOfT 2 
BASCODE ModeAodioALaw 1 
BASCODE ModeAudioAJUw 2 
BASCODE ModeAudioAJUw 3 
BASCODE ModftAudioULaw 1 
BASCODE MacUAiutioULaw 2 
BASCODE ModcAudloUL*w~3 
BASCODE ModcAudtoCm 1 
BASCODE ModcAttd&oCTn 2 
BASCODE ModeAudJoGTO 3 
BASCODE ModcAudiottK 
BASCODE Mod*Audio32K 
BASCODE M«dcAudio24K 
BASCODE MadeAudioJK 
BASCODE ModeAudio64K 
BASCODE Mod«Ao4ioU5K 
BASCODE Mod*A«<Uol52K 
BASCODE Mod€Audio25cX 
BASCODE Mod«Audia3S4K 

II VIDEO MODES 
BASCODE Mod<VtdcoOfT 
BASCODE Mod«VtdcoK261 
BASCODE ModaVldcodxiprmtl 
BASCODE ModtVideoLSO 
BASCODE ModcVldcoConposUe 
BASCODE ModcVklcoCIF 
BASCODE ModeVtdeoOCIF 
BASCODE Mod«Vldco4ClF 
BASCODE Mod*VtdeoClF240 



■ 0x0000000 1 

* 0x00000002 

* 0x00000003 

* 0x00000004 

■ 0x00000005 

■ 0x00000006; 

* 0 x 00000007 

* 0x00000008 

■ 0x00000009; 

■ 0x0000000* 



> 0x0000000b: 
i OxOOOOOOOc 

• OxOOOOOOOd 

• OxOOOOOOOc: 
i OxOOOOOOOf : 

■ OxOOOOOOlO; 

• 0x00000020; 
» 0x00000030; 

■ 0x00000040; 

> 0x00000050 



- 0x20000001 
* 0x20000002; 

- 0x20000003: 
» 0x200000 
m 0x20000005 

- 0x20000006 

- 0x20000007 
■ 0x20000008 

- 0x20000009 
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6645 



6650 



6655 



6660 



6665 



6670 



6675 



6680 



6685 



6690 



6695 



6700 



6705 



BASCODE ModtVid*oFr*~ 
BASCODE ModtVideoUnfrw 
BASCODE ModtVldcoFajtUpdtu 
BASCODE Mod*VkUoD+cOa 
BASCODE Mod«VidcoDocOfT 
8 ASCODE ModcVfdeoSpUiOo 
BASCODE ModcVkfooSptitOff 

'/IMAGE MODES 

BASCODE M«i«ISOSuntilPtctureLowS«H*dI>«ta 
BASCODE Mod,lSOS«nliiP«ureHitl^^^ 
BASCODE MotULSp-dDwUf ~ Wpe<Wua 
BASCODE MedcHicfaSpccdDataFu 
BASCODE M©dcrPECLowSpwdD«tt 
BASCODE Mod«JPECHichSp««dD*u 

//LOW SPEED DATA MODES 
BASCODE Modcl*wSpcc4DauOfr 
BASCODE ModcL«wSpccdOaiA300 
BASCODE Mo4U*wSpcc4DauU00 
BASCODE ModU^wSp— dDmta410Q 
BASCODE Mod«L«w5pc«dDmtA*400 
BASCODE ModeLowSpcwiDMAMOO 
BASCODE ModeUwSpccdDaUMOO 
BASCODE Mod<LowSpecdDaui4400 
BASCODE Mod«Lo«Sp««dDaU16K 
BASCODE M«S«LowSp*cdD«u24IC 
BASCODE MmULavSpcmUHUUK 
BASCODE M«kL*w5pc<dI>«l*40K 
BASCODE M«feLo«Spc«dD*t*«K 
BASCODE Mod«L«wSp*«dDat*SfK 
BASCODE Mod«L*wSpc*dD*i«42K 
BASCODE Mod«LowSp«dD«t*44K 
BASCODE ModcLowSpetdDataVuiftble 

// HIGH SPEED DATA MOOES 
BASCODE ModcHJchSpatdDicaOCr 
BASCODE Mod€Hi«hSpc«fiDmt«64K 
BASCODE ModcifitbSpecdDmUUftK 
BASCODE M«UHiffaSpt«dDa(jmK 
BASCODE Mo<UHAthSpe«iDmU2S«C 
BASCODE ModcHJffaSpecdDaUlUK 
BASCODE ModtHithSpt«dD« u38 4K 
BASCODE ModtHlfhSpMdDtiASUX 
BASCODE ModcHlchSpMdOmu7aK 

BASCODE ModcHic*xSpe««LDmtal£36K 
BASCODE Mod«Hl«hSp««iD»uV*nxbk 

// APPLICATION MODES 

BASCODE ModeN«utnJ 

BASCODE ModcEacrTpcloaOo 

BASCODE ModeEocrypUooOfT 

BASCODE ModcAudteLoopteck 

BASCODE ModcVld— 1 •opfaacfc 
BASCODE ModtRotrtetOn 
BASCODE Mod*JU«rtrtOfr 
BASCODE M od«Dt«lUiLoopb«ck 
BASCODE ModcLoopfcstkOfT 
BASCODE ModeCocapa«a«rfBOu 
BASCODE M«d«Co«paotc6TOrr 
BASCODE Mod«CurwrOnU>wSp«*dDau 
BASCODE Mod*F«*OoLowSp*«lD*u 
BASCODE ModcFmxO&HicbSpecdlfeu 
BASCODE Mod«Vl20LowSpt«dD«t a 
BASCODE ModtVUOHlfhSpwdD.t* 



• 0x2000000* 

• 0x2000000b 
' OUOOOOOOe 

1 QOOOOOOOd: 



• OUOOOOOOe 
•OOOOOOOOf: 
' 0x20000010: 



■ 0x20000020: 
» 0*20000030: 
1 0x20000040: 
1 0*20000050: 
• 0*20000060: 
' 0x20000070; 



-0x30000001 

- 0x30000002: 

- 0x30000003 

- 0x30000004 



• 0x30000005 

• 0x30000006: 
■ 0x30000007; 

0x30000008; 



0x30000009: 
' 0x3000000i 



• 0x3000000b; 



• 0x3000000c 



" Ox3000000il; 



' Ox3000000e; 



Ox3000000f: 
■ 0x30000010: 
' 0x30000020; 



•0x30000030; 
' 0x30000040; 
• 0x30000050 
' 0x30000060; 



•0x30000070; 
'0x30000080: 
■0x30000090: 
•0x300000x0; 
' OOOOOOObO 
0x300000o0: 
- Ox300000dO: 



- Ox300000cO 



• 0x20000060; 
' 0x20000070: 

• 0x20000080: 
1 0x20000090: 
' 0*200000x0; 



• 0x2000000; 
' 0x200000c0; 
1 Ox200000dO; 



Ox20000QcO: 



' 0x200000f0; 
. 0x20000100: 
» 0x20000200: 



- 0x20000300; 



0x20000400: 

• 0x20000500; 

• 0x20000600 
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PHYSICAL DEVICE INTERFACE HEADER FILE 



6710 



6715 



6720 



PHYSICAL DEVICE INTERFACE HEADER FILE 
Cor 

VJKTVMJZBD MULTIMEDIA CONNECTION SYSTEMS 
ABSTRACT 

This source module contains header tnfomuuoa used primarily by the server components to any VirruaUzcd Multimedia Connection 
System (VMCS) inipteinencsxion. If the special keyword symbol " VCO BUELD" is defined prior to inclusion of this file a 
indicates to die compiler thai a VCO is being built, and (he class *VL* must be defined ta lull. If this symbol is not defined, a 
indicates dial a VCO diem application is being built, and only die header files needed eo access members of class VDI. and ms pure 
viruaJ device control override member runcoorts m class *POC". need be considered dunnf the software truiid process, la this way. 
both the server (VCO) and client components of the VMCS derive symbolic dcfinioons from the same source code base, but no 
vendor specific (device -dependent) code is at any ome visible to the device -independent client i 



6725 



(SOURCE FILE: 



PDl.H) 



PROGRAMMING NOTES 
1. This module contains only C+ •+ source code and soucaired comments using the " // " 
to the standard C comment notaoon using * /• •/ "). 



nocaoon to denote comments (in iddioon 



6730 



Symbols defined in die VDI Software Control Interface are shown in boldface type below. 



6735 



'include < OS.H > 

fmciude < BASCODES.K > 

# include < MCLH > 

'include <VDLH> 



// Include eperiang system and user interface API 
// Include bit-rate allocation signal todicadons 
// Include Media Control Interface device control coosouus i 
// Include dcfuuooo for die VDI and all less derived < 



DECLARATION FOR CLASS VL 



6740 



6745 



6750 



6755 



6760 



class VL: public VDI { 
prot ected * 

VUconst char* tniFtle): 

virtual w VLO; 

virwal const char* GcrCUssNameO ( return "VL"; J; 
fifdef VCO BUILD 



-LI 



#endif 



Vendor-specific special purpose mcmben needed to implement more-derived PDl 
members are defined here. These functions must provide all services necessary to 
format data and control devices in ■ way consistent wtth those necessary to best implement 
die overrides to the pure virtus! device control members in die VDI. 



); 

DECLARATION FOR CLASS PDI 



6765 



6770 



class PDl: public VL ( 
private: 



// PDI DATA STRUCTURES 
p Label: 
pVcnion: 
DEVCAPS Local: 
int nModes: 
int nCaps: 
XREF Caps(MasCaps|; 
XREF Modes! Ma sM odes): 



// Ptr to VCO label soring 

// Pxr id VCO version scrag 

// Local device capabilities listing 

// Number of entries ui 'Modes to Caps* tref list 

// Number of entries in "Caps to Modes" xrtf list 

// "Caps to Modes' srel list 

// "Modes co Caps* tref list 



no~VM<U1 I 
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6775 



6780 



6785 



6790 



6793 



6805 



6810 



6815 



6820 



6825 



6830 



6835 



const DEVICE 

inc 

im 

tra 

im 

inc 

const char* 
MCO BINDING 
HMCO* 
HMCO 



Devices. 

DevfMaaDevicesJ; 

nMco: 

nAudioObj: 

nVidcoOtf: 

aimtfcObj; 

nDaoObj; 

pMediaLabclQ; 

pMedufltadirti: 

phMco: 

hMcofMixMcoTypcj. 



// Number of encapsulated devices 

'/ Encapsulated do tee chxm 

ft Number of meda Ctrl objects currently available 

" Wu »**r of audio objects currently available 

tl Number of mooonvtaeo objects 

ft Number of objects 

« Number of dau objects 

'*i L*Z W * my 10 Ctrl object Ubels 

// Prr to linked l«i of current media cert object btndint, 
/ Pumo linked list of all available media col objects 
" Default meda Ctrl object handles 



PDUconss char* JniFtfel; 
virtual -PD10: 

virtual const char* GerCUssNarneO { return -PDI\ J. 

// PURE VIRTUAL OVERRIDES FOR VDI npvirr m^n, 
RESULTCODE DevOpenf BOOU DEVlCE CONT *°<- MEMBERS 

RESULTCODE DcvCI**e< BOOL); 

SSs^— — , 

RESULTCODE DevAsuweH CALLPARAMAJm *. 
RESULTCODE D«vAb«n0; wv "- rAJtAM *- 4 * * 
RESULTCODE DevGetCaUInfo* CALLPARAM* ); 

RESULTCODE Dev^C^* MCO JTYPEJKCO_5ETTrNG, D WORD.BOOL. BOOL 
RESULTCODE DevEm«Cootxol( EMUCONTROLOP ); 

RESULTCODE DevXmt0au( BYTE* (nt iiurn fr*™ 

RESULTCODE ^D^'ffiiS^gSSSSSft * 

RESULTCODE D.rSetMed<X BASCODEVim ,. 
RESULTCODE Dt.StadC.pi BASCOOE*. J], 



— » Dt*GttMod«LabeJ( BASCODE )• 
I cbar* DtTGtlCspLtbcU BASCODE »; ' 

MCOPARAM* DerCtlMc* HMCO )• 
HMCO D«G«tMcoHaadl*4 com cfear* )• 
HMCO Dt.GtlMcoHmndW MCO TYPE ); 

D^&tD.UuhMc^ MCO TYPE. co on cJur- )• 
RESX«.TCODED.TS«UW.^«^MCO:TYptHMCO)r 

RESULTCODE D»S«C«^ CONFIGPAJtAM* )• 
RESULTCODE DtTCCoofl* CO^CP^Ram* J ; 

RESULTCODE DerSrtTuatoutC DWORD ); 

RESULTCODE DtW.ri/.Bandwidu* BASCODE.BASCODE ); 

RESULTCODE D,.,OCo«« IOCOtfTROLOP.DWORD.DWORD.BOOL.BOOL , : 
« CALLBACK MEMBERS ACCESSED BY PROTCOL STACK AND MAC LAYER 
vo* fa, Ne^orkEvcntf DWORD EvemCade. DWORD _ PlrM ,. 

void fa, pual DeviceEventI MCWEADER' _pMciHeid*r ): 



XXSD: <VWO 090021 3M Jj. 
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GENERAL VMCS HEADER FILE 

GENERAL HEADER FILE 
for 

VIRTUAJJZED MULTIMEDIA CONNECTION SYSTEMS 

6845 ABSTRACT 

This source module corns ins header miormaoon used by both client and server components in any Vimtakied Multimedia 
Con/uesxcA System (VMCS) tmolemeotaooo. In this way. both the server (VCO) and client components of the VMCS derive 
symbolic deftruooru from the tame source code base. This class serves as a capstone to the VCO class soucturc: so as so present 
every VCO client with exactly the same member functions accessible from me same class type. The addmon of tmptemencaoon- 
6850 specific members to this class can proceed without effecting VCO interoperability or standard VMCS documenosooa. 

(SOURCE FILE; VCO.tto 

PROGRAMMING NOTES 

6855 This module contains only C+ *• source code and structured comments using the * // * notaoon to denote comments (in addtdon to 
the standard C comment notation using * /• •/ ") 

------------ - ••--------------------»--•■---«'------------■.-- — -•/ 

# include < PDl.H > // Include definition for the PDI and all less derived classes 

6860 

DECLARATION FOR CLASS VCO 

6865 class VCO: public PDI ( 
public: 

VCO< const char* _lniFile): 

6870 

virtual -VCOO; 

virtual const char* GetCIassNameO ( return * VCO*; }. 

6875 private: 

/• Lmplemenaoon specific members go here, including memoers to support : 
...Dynamic link library trnpternencauon 
...Access re sm coon for VCO Clients 
...Safeguards against re-emrancy and mulo-inscsnaauon 

6880 •/ 

): 
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SAMPLE VCO CLIENT APPLICATION 



6883 



6915 



6920 



SAMPLE 
VIRTUAL CONNECTION OBJECT 
CUEKT APPLICATION 
for 

6890 VIKTVAUZED MULTIMEDIA CONNECTION SYSTEMS 

boo me ,oc4l remott , oooni ,„ aXTS^ZSLTtLT^ m ° m " red IOM " y F ° t CUnry « « to 
d» «.«U . », _ uaoon. Requisite Trror c^lSt «^££T " "'^ — ■ • ~ 

69Q0 (SOURCE FILE. VCOCUEMr.CPn 

«05 3 O.«0, reU- „ opc^n, , yMem APr , ^ ^ Ipeclflc , oflhealef ^ ^ ^ ^ fof ^ 

i f^'^^f «^ lZ l ^:'J : ™ r ?lzT c ' ,re " b0M6e< «» 

6910 'include < VCO.H > 



« Include uandwd VCO Softw.rr Conor)! Internee defuaooo 
'define NO NB LOCK 0 ,/ « , _ 

// Used co tct caiU to W Wockin* ' mode (immed»« rrtun,, 



*define NOTmCA-nON.RECEIVER.MEMBERi.CUu. .Member IV 

'define EVENTPROC NoofierM_<W#_Member< EVENT W . 

DWORD Pinmi 

DWORD "Pinmi! 

STATION* _pSaoon. 



6923 CUii' pNRO: \ HNOTIHER _hNonfier ) ( \ 

} -n, < pNRO ? P NRO-> Member, U. .P.rrm,.. .P^ j.S^aon. JuNobfier > : 0 ); V- 

^ " ''ZT^ZZ. " ,PeC,fy — » - VCO. ,ucb „ ^ n cre4an< 

/define NOTlFICAT I ON.PROC( _CU„. Member , NoafierW.CUsur Member 
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6935 •* VCO Conferencing Object Class used by client application to cscaotish automaoc media Ctrl toopfeack 

connection to remote station. Log! all re I event connection and media control trace tn/ormaoon to a fdc. Also, 
all trace in/ormaoon cmanaong from the VCO itself, reUang to the operauoru of the VCO. are displayed (in 
real-dme) on me console display. 

•/ 

6940 class Con/Object ( 



6943 



6980 



BOOL IsAcovc: // True rf the current session is acove 

// Constructor to establish session wuh remote staoon (nutate call, then set looobacJc) 
Con/Ob jectt VCO A _Vco. crur- jvTtaceFUe): 



// Destructor ends session wich re moo; station (hangup) 
6950 'CoitfDbjectO; 



VCOAt Vco; // Reference to default VCO for session 

6933 char* pTraceFile: // Ptr to fUespec for session tnce file 

HNOIU1ER hNoofyNodfier: // Handle for event noaftcaoon signal 

HNOTTFTER hDuplayNoofwr: // Handle for console message display signal 

6960 // Noafier handling procedure for connection and VCO events rxaasmmed to dus client class object 

DWORD NooryProcl EVENT Id, 

DWORD "Pmraml. 

DWORD "P»rmm2. 

STA TION* ^Station, 
6963 HNOTTFTER hNobfter ); 

// Nobfier handling procedure to display die VCO teat stream transmitted to this client class object 
DWORD DispUyProcXEVENT Id, 

DWORD ~ Parana. 
6970 DWORD Parana. 

STA TION* IpStaaoa. 
HNOTTFTER ruNobfter ): 

): 

6973 Create 'rnwiftV for all the VCO event handling procedures used to direct trigger noaficaoons (and text 

messages) to members tn the *ConfObject* nooftcaoon receiver object (NROV 

•/ 

NOTIFICATION _ R£CETVER_M EMB ER( ConrObject. NonfyProc): 
NOTIHCATlON~ RECEIVER* MEMBERf ConfObject. Display Proc); 



ConfOb|ect::Con/Objecr(VCO& _Vco. char* _pTraccFilc) ( 



/* Determine if constructed VCO supports device modes necessary to a conference 

where audio, video, and binary m/ormarson wtil be concurrently shared. 

6983 •/ 

LsAcdve m 0: 

Vco - ^Vco: 

pTraceFile - ^pTraceFile: 

hNootyNodfter - 0: 

6990 hDispJayNoofier - O; 

BOOL CanDo Audio - Ch 

BOOL CanDoVideo - 0; 

BOOL CanDoData - 0: 

DWORD EvcmMaak - New Rev Mode | NewXialMode | NewVeoStaU | NewCaUState: 

6993 PEVCAPSALocaKUps - Vco.CetDvvieeParmmO.Cape. Local: 
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for< inii - 0; , < LoeiiCap».«C«p.. ,** , , 
7005 J 

If medu Clrt wPPonw. open VCO for tttaae 

#/ nooflcaoom and then iiuoaitze device* 

if (CmnDoAudio CanDoVideo A£ CanDoData) ( 
Vco.NewNotuTert hNoofyNotifier. 

N07TnCATION,PROC(ConfObicc,. NouryProcK 

EvemM*** ); 
Vco.Eoab4cNo<4Acr( hDiipUyNodfter ); 

Vco.NewNoctflcrt tl DgUy Wooficr. 
7020 NOTinCAT10N_PROC(CoitfOb JC ci, DupUyProcK 

NewT«raOutpuj >: 
// Ac«n* *, of VCO „ ^ dijpU eoniote 

IiAcove ■ |; „ 

// Mart thu teuton as currently active 



7010 



7013 



7023 



7035 



7040 



'' O*.™* ; ^dicu, (lJ j ure » uippon open*™. »„d „«. 
) el " PrU,rf( Sc'«- VCO ■ncap,,* of commn ^ 

ConfObjeet;: "Con/Objee*) { 



Vco.QomO* 

7045 " encapsulated sub-system (w„ t unni complete) 

// Delete the nodficaoonj 
Vco.DeieieNetineft hNoofyNoofier )• 
Vc*.DeJ«t*NoUfler< hDUpUyNodfkr ); 

^ ^ pnnrfCVCO has been closed.*'); 

DWORD Con/Object:: Display Proc( EVENT U 
7033 DWORD >aWml, 



7060 



DWORD 'Paraaui 
ST ATION* j>S*xknl 
HNOIUTER hNodfier > ( 

pnntff •%x\n*.(char*) Parana J* /# *^ , 

" Du ' ,U y «" ™casaie on the console (std output) 
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DWORD ConfObfcct::NotifyProc( EVENT td. 

DWORD Parasol. 

DWORD 'Puul 

7065 STA TION* jtfanoa. 

HNOTTFTER _hNooikr ) ( 



// Process ail events that trigger noaftcaoon 
iwwch < Jd ) ( 

esse New Rev Mode: // Log new mode set by remote staoon 

Vco.ToTermioalf "Mode Sec by RemoteSaoon ( %t |\o". 

Vco.CetModeLAbcK(BASCODE) Panunl) >. 



7070 



7075 



7060 

esse NewVcoStftte: // Handle new VCO state 

switch ( (int)_Pararat ) ( 

esse VcoOpes: tf Call default remote station when opened 

Vco.ToTermin*K 'Successful VCO open: Calling default remote suooo.ta' ); 
7085 Vco.CaiU 0. 0. NO KB LOCK): 



esse New XmMoeU: // Log new mode set by local staoon 

Vco.ToTcrttuaalf 'Mode Set by Local Season | *s |\n\ 

Vco.CeiMedeLabeiffBASCODE) P tram I) ); 



Vcodnst: // Log new VCO close state, then mark session inactive 

Vco.ToTermsnaK "VCO has been closed. ui" >; 
IsAcave - 0: 



case VceFaStd: // Log VCO error state, then mark: session tnacove 



7095 Vco.ToTcnmns* 'VCO Error Condition ( ft s|\n* . 

Vco.GctVcoStalcJ ah»K<im)J>iraswl): 

UAcnve • 0: 



7100 break: 
J 

case NewCeflScnte: // Handle new VCO call sate 

switch ( (im)Parsml) ( 

7105 case CaflDtocenaected: ft Log disconnect of call: end output to trace file: mark session mactrre 

Vco.TeTerminaW 'Disconnected from Remote Staoon, ta* ); 
Vco.DctachTermFrocoX TermODevFUe ): 
IsAcove -0; 
break: 

7110 

case CaflCfmnrrrtng: // Begin trace file output: trace scut of call conoecoon evens 

Vco-AlUchTermToFQef pTraccFkc) : 
Vco.TeTencttnaJf 'Connecting To Remote Staoon. \n" J; 



7115 

case CaOConDected: // Upon connecoon. trace fonnaoed session in/orrnaooo to file 

Vco.ToTcrasBalf 'Connected to Remote Scaoon: Listing connecooo data.\n* ): 
Vco.UsiCallPareaaO: 
Vco.UstMCOiO: 
7120 Vco.LusCoeuseciJonCapsO: 

// Loop audio, video, and data input signals back to remote staoon 
Vco.ToTertntnaU 'Seeing up media col toopback...\n' 1: 
VcaM<itinC*mrrvt( Audio In. AoschTo. AudioOut ): 
7125 VooMt&AComxroH Video In. AtacbTo. VideoOuc >: 

Woo.MtdiaControti DataJn. AnachTo. DataOut ); 
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7130 



7133 J 



7133 



ft Set local hjQjo and video (mic and dianiavi ■» - . , 

Vco .^O«o^ Aud*in^^To^ ,nPW ,,rmlS ^ "* 

VcoM*di*C*m*o« Videoin, AcachTo. VtdeoOs ); 



brat: 

) 

7140 reoani 0: 

) 

' # w^iT ^T" 000 " ^ Loop, «tck til tud». vkIoo. tnd da* channel, wne« 

7143 •/ du f noKic teuton m/onnMon co backup «ort to CWc<> wtle " 

)( 

// Consaics a selected VCO 
7130 MyVco Vco< •C:\VCO.Wr >; 

// Coosoua irc conferencing object 
MyCUentApp Con/Objec4 My Vco, *C;\VCO,LOQ- ) : 

// Block while die cotmccovtry lexuoa U active 
Mute < MyCliemApp.UAcovc ): 
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What: is claimed is: 

1. A multimedia connectivity program residing in 
computer readable memory, said connectivity program when 
executed on a computer providing to an application 

5 program multimedia connectivity services through a real- 
time multimedia device control subsystem including 
components selected from among a plurality of multimedia 
devices and a plurality of real-time multimedia protocol 
stacks, said program comprising: 

10 a single binary object encapsulating a virtual 

device interface and a device control interface, said 
virtual device interface including a plurality of virtual 
methods that represent logical operations available to 
the application program for controlling said multimedia 

15 device control subsystem, said plurality of virtual 

functions being completely independent of the components 
within the device control subsystem, said device control 
interface mapping said plurality of virtual functions to 
physical control methods which control the components of 

20 the multimedia control subsystem. 

2. The multimedia connectivity program of claim 1 
wherein said device control interface comprises a 
plurality of media control objects which represent 
audiovisual and binary data streams associated with the 

25 components of the plurality of devices and/ or real-time 
multimedia protocol stacks. 

3. The multimedia connectivity program of claim 1 
wherein the virtual device interface is configured to 
present a logical representation of the multimedia 

30 connectivity services provided by the connectivity 
program. 
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4. The multimedia connectivity program of claim l 
wherein said device control interface comprises a 
visualization layer and a physical device interface 
layer, said visualization layer located between said 
5 virtual device interface and said physical device 
interface, said physical device interface directly 
interfacing to the device control subsystem to provide a 
physical implementation of services requested by the 
application through the virtual device interface, said 

10 visualization layer residing between the virtual device 
interface and the physical device interface layer and 
configured to translate and map device control mechanisms 
employed by the underlying multimedia control sub-system 
to representations required by the virtual methods of the 

is virtual device interface. 

5. The multimedia connectivity program of claim 2 
wherein the plurality of media control objects provides 
the multimedia connectivity control program with a pool 
of media device signal resources. 

20 6 - The multimedia connectivity program of claim 5 

wherein each of said plurality of media control objects 
is classified as at least one of type of the group 
consisting of an audio type, a video type, an image type, 
and a binary data type. 

25 1 ' The multimedia connectivity program of claim 6 

wherein each of said plurality of media control objects 
represents a signal from the group consisting of a signal 
from a remote station, a signal to a remote station, a 
signal from a local output device, and a signal to a 

30 local output device. 
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8. The multimedia connectivity program of claim 7 
wherein operations performed on the plurality of media 
control objects by the physical device layer under 
control of the virtual device interface implements a 
logical software switching mechanism connecting incoming 
signal paths to outgoing signal paths. 

9. The multimedia connectivity program of claim 1 
wherein the virtual device interface implements a 
plurality of public member functions, said virtual 
functions being a subset of those public member functions 
and wherein said plurality of public member functions 
represents all of the public member functions in the 
single binary object that are accessible by the 
application program. 

10. A computer programmed to provide to an 
application program multimedia connectivity services 
through a real-time multimedia device control subsystem, 
the multimedia device control subsystem including 
components selected from among a plurality of multimedia 
devices and a plurality of real-time multimedia protocol 
stacks, said programmed computer comprising: 

a virtual device interface and a device control 
interface, both of which are encapsulated in a single 
binary object, said virtual device interface including a 
plurality of virtual methods that represent logical 
operations available to the application program for 
controlling said multimedia device control subsystem, 
said plurality of virtual functions being completely 
independent of the components within the device control 
subsystem, said device control interface mapping said 
plurality of virtual functions to physical control 
methods which control the components of the multimedia 
control subsystem . 
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11. A computer implemented method of providing 
multimedia connectivity services through a real-time 
multimedia device control subsystem, the multimedia 
device control subsystem including components selected 
from among a plurality of multimedia devices and a 
plurality of real-time multimedia protocol stacks, said 
method comprising: 

defining and supporting by computer implemented 
steps a virtual device interface; and 

defining and supporting by computer implemented 
steps a device control interface, wherein both of said 
virtual device interface and said device control 
interface are encapsulated in a single binary object, 
said virtual device interface including a plurality of 
virtual methods that represent logical operations 
available to the application program for controlling said 
multimedia device control subsystem, said plurality of 
virtual functions being completely independent of the 
components within the device control subsystem, said 
device control interface mapping said plurality of 
virtual functions to physical control methods which 
control the components of the multimedia control 
subsystem. 
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FIG. 3a 



FIG. 3b 



FIG. 3 
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FIG. 7-1 
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IS 

llNE RINGBACK^ 
EVENT 

? 



IS 

'LINE CONNECTED* 
EVENT 

"NO 

IS" 

tlNE BUSY^ 
EVENT 

? 

'no 



YES 



HANDLE RINGBACK SEQUENCE 
FOR VARIOUS EXISTING CALL 
CALL STATES 
[CALL EXECLINERINGBACK] 



YES 



HANDLE CONNECT SEQUENCE 
FOR VARIOUS EXISTING CALL 
CALL STATES 
[CALL EXECLINECONNECT] 



YES 



HANDLE BUSY SEQUENCE 
FOR VARIOUS EXISTING CALL 
CALL STATES 
[CALL EXECLINEBUSY) 
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TEXT MESSAGE 
ISWER FAILURE" 
TOTERMINAL) 




TUNES 

pa 

INECT) 




li 






OH 








CO i ^ 







UJ 

3 ? 

kgg 




' PROCEDURE 
v (EXECUNE- 


/ Q 

/la 

\^8 

\Oco 


OUTPl 

"L 
(CAl 


\ Q 







C^co 

^8 



CO 
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ENTER 
PROCEDURE 
[MEDtACONTROLl! 
[QUERYMODE] 



VERIFY IF VCO IS 
FULLY OPERATIONAL 
(CALL ISVCOENABLED) 




VERIFY MEDIA ACCESS CONTROL 
DRIVERS ARE OPEN AND MEDIA 
DEVICES ARE AVAILABLE FOR USE 
(CALL GETDEV1CEPARAM) 



SET RETURN VALUE 
TO INDICATE VCO 
DISABLED 



ARE 
MEDIA DEVICES 
AVAILABLE 

? 

NO 



YES 



SET RETURN VALUE TO 
INDICATE MEDIA DEVICES 
ARE UNAVAILABLE 



(exit) 



VERIFY "MCO" SETTING IS 
ACCESSIBLE AND THAT THE 
MEDIA DEVICE SUBSYSTEM 
SUPPORTS ITJSSUE MCO 
COMMAND TO PDI (CALL 
DEVMEDIACONTROL) 



ARE 
MEDIA DEVICES 

CAPABLE 

? 

*NO 



YES 



SET RETURN VALUE TO 
INDICATE MEDIA DEVICES 
INCAPABLE OF COMMAND 



SET RETURN VALUE TO 
INDICATE MEDIA DEVICES 
CAPABLE OF COMMAND 



FIG. 21 
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ENTER 
CONSTRUCTOR 
[VCO] 



TOR^ 



ENTER 
DESTRUCTOR 



CONSTRUCT TERMINAL 
EXCEPTION. AND A „„ 
EVENT-DISPATCHING CLASSES 
WITH SPECIFIED PARAMETERS 



I 



INITIALIZE SYSTEM INFO 
DATA STRUCTURES TO 
KNOWN STARTUP VALUES 



I 



RESTORE INTERNAL VCO 
CONFIG TO VALUES IN 

BACKING STORE 
[CALL REGRESHCONRG) 



-OR^ 



1 


r 


SEND VCO SHUTDOWN 
TEXT INFORMATION TO 
TERMINAL OUTPUT 
(CALL TOTERMINAL) 



I 



ATTACH TERMINAL OUTPUT . 

AND INPUT TO DEFAULT^ r*H 
INPUT/OUTPUT RLE/DEVICE 
(CALL ATTACHTERMINAJ— ) 



A 



START EVENT DISPATCHER^ 



OUTPUT TEXT MESSAGES 
SHOWING DEV1CE/SW 
VERSIONS & CONRGS 
FOR THIS VCO 
(CALL TOTERMINAL) 



DETACH AND 
DELETE NOTIFIERS 
ATTACHED TO 
VCO DEVICES 

- 



CREATE NOTIFIERS AND 
ATTACH EACH TO 
A VCO DEVICE 



ENABLE VCO 
EMULATION MODE 
IF SPECIFIED IN 
CONFIGURATION 



I 



ENABLE VCO EMULATION 
MODE IF SPECIFIED IN 
CONFIGURATION 



START EVENT 
DISP ATCHER 

I 



FREE ALLOCATED 
BUFFERS AND 
OBJECTS 



FIG. 24 
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ENTER 
PROCEDURE 
[OPEN1 



VERIFY IF VCO IS 
FULLY OPERATIONAL 
(CALL ISVCOENABLED) 



OUTPUT TEXT MESSAGE 
•PCI:OPEN(...r 
(CALL TOTERMINAL) 




OPEN ALL ASSOCIATED 
VCO MEDIA/CONNECTION 
DEVICES [CALL DEV OPEN 



SET RETURN VALUE 
TO INDICATE VCO 
DISABLED 



INCREMENT VCO 
REFERENCE COUNT 
(UPDATE FIELD IN 
DEV1CEPARAM) 



INCREMENT VCO 
REFERENCE COUNT 
(UPDATE FIELD IN 
DEV1CEPARAM) 



J 



UPDATE VCO 
CONFIG FROM 
BACKING STORE 
(CALL RESTORECONFK3) 




SET RETURN VALUE TO 
THAT RETURNED BY 
CALL TO PCI 





RESET ALL CALL PARAMS 
TO DEFAULT UNCONNECTED 
VALUES [CALL RESETCALL) 








r 




RESTORE DEVICES TO DEFAULT 

UNCONNECTED MODES 
[CALL RESTOREDEFAULTMODES] 



I 



OUTPUT TEXT MESSAGE 
"NEW CUENT ADDED' 
(CALL TOTERMINAL) 




SET RETURN VALUE TO 
INDICATE VCO OPEN 
OPERATION SUCCESSFUL 



FIG. 25 
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ENTER ^\ 
PROCEDURE ) 
[CLOSE] S 

\ 



VERIFY IF VCO IS 
FULLY OPERATIONAL 
(CALL ISVCOENABLED) 




OUTPUT TEXT MESSAGE 
•PCICLOSB...)" 
(CALL TOTERMINAL) 



RESTORE DEVICES JO 
DEFAULT UNCONNECTED 
MODEJCALL RESTORE- 
DEFAULTMODES) 



J 



SET RETURN VALUE 
TO INDICATE VCO 
DISABLED 



DECREMENT VCO 
REFERENCE COUNT 
(UPDATE FIELD IN 
DEVICEPARAM^ 



CLOSE ALL ASSOCIATED 
VCO MEDIA/CONNECTION 
DEVICES _ 
(CALL DEVCLOSE) 



DECREMENT VCO 
REFERENCE COUNT 
(UPDATE FIELD IN 
D EVICEPARAM) 

T 



savTECUrrENI vcO 



CONFIG TO BACKING 

STORE 
(CALL STORECQNFIG) 




SET RETURN VALUE TO 
THAT RETURNED BY 
CALL TO PCI 



OUTPUT TEXT MESSAGE 
•VCVO CONFIG SAVED' 
(CALL TOTERMINAL) 



I 



OUTPUT TEXT MESSAGE 
XUENT REMOVED* 
(CALL TOTERMINAL) 




SET RETURN VALUE TO 
INDICATE VCO CLOSE 
OPERATION SUCCESSFUL 



T 



FIG. 26 
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ENTER 
PROCEDURE 
[HANGUP] 



VERIFY IF VCO IS 
FULLY OPERATIONAL 
(CALL ISVCQENABLED 




YES 



YES 



SET RETURN VALUE TO 
INDICATE VCO DISABLED 



SET RETURN VALUE TO 
INDICATE VCO NOT OPEN 




SET RETURN VALUE TO 
INDICATE THAT CALL 
MUST BE CONNECTED 



OUTPUT TEXT MESSAGE 
•HANGING UP CALL" 
(CALL TOTERMINAL) 



ISSUE CALL ABORT 
COMMAND TO PCI 
(CALL DEVABORT) 




EXIT 



SET RETURN VALUE TO 
INDICATE RESULT OF 
ABORT COMMAND 



FIG. 29 



SUBSTITUTE SHEET (RULE 26) 



WO 98/09213 




PCTYUS97/15018 



35/35 



OPERATION 


DESCRIPTION 


SetConFocus 


Set conference focus to specified station 


QueryContFocus 


Determine identity of station currently in focus 


SetConfChair 


Set conference chairman 


QueryConfChair 


Determine identity of conference chairmen 


AddStation 


Add station to conference 


RemoveStation 


Remove station from conference 


BroadcastAudio 


Enable or disable broadcasting of audio conference 


BroadcastVideo 


Enable or disable broadcasting of video conference 


BroadcastData 


Enable or disable broadcasting of data conference 


GetNumStabons 


Get number of conferees 


GetStationList 


Get list of conferees 


GetStationCaps 


Get capabilites of particular conferee 


GetStationAudio 


Get audio of particular conferee 


GetStationVideo 


Get video of particular conferee 


GetStationData 


Get data of particular conferee 


GetStationldentity 


Get numbers and station label of particular conferee 



MULTIPOINT CONTROL OPERATIONS 

FIG. 30 
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